System for video playback using a server-generated manifest

Abstract

Systems for video playback using server-generated manifests are disclosed. An apparatus and method are disclosed for using a server to generate per-user manifest files for providing a unique viewing experience and a proxy module localized to a video player that receives the manifest file for measuring video playback events with frame accuracy. In one aspect, a server can be used to generate a manifest file for guiding a video player to play requested video content in a video stream along with advertisements or other potentially desired alternative content. A proxy module localized to the video player can parse the video stream to inject triggers at frame-accurate positions where measurement may be desired, such as at precise frames where alternative content starts, stops, and / or reaches a midpoint relative to the requested video content.

Description

[0001] This application is a divisional application. The application number of the original application is 201780011328.5, the filing date is May 10, 2017, and the invention title is "System for Video Playback Using Server-Generated Manifest". Technical Field

[0002] The subject matter disclosed herein relates to a method for measuring video playback events that can be unique for each user during a video stream. More particularly, a method and apparatus are disclosed for using a server to generate a per-user manifest file for providing a unique viewing experience and a proxy module of a video player native to receiving the manifest file for measuring video playback events with frame accuracy. Background Art

[0003] Video streaming allows video content to be delivered via the Internet to a video player. Video content is a video signal generated by a content provider for distribution to video consumers. The video signal can be provided in an uncompressed file format such as a Serial Digital Interface (SDI) format or in a compressed format such as a Moving Picture Experts Group (MPEG) file format or a Transport Stream (TS) file format. The video signal is sent to an encoder, which converts the file into a live stream signal. The live stream signal is preferably a segmented data stream that can be transmitted via the Internet using the standard Hypertext Transfer Protocol (HTTP). The live stream signal can include multiple streams, where each stream can have a different data rate and / or a different resolution.

[0004] Two common formats for live stream signals include HTTP Live Streaming (HLS) implemented by Microsoft and MPEG-based HTTP Dynamic Adaptive Bitrate Streaming (MPEG-Dynamic Adaptive bitrate Streaming over HTTP, MPEG-DASH) implemented by web browsers such as

[0005] The live stream signal and manifest file are stored in one or more content delivery networks (CDNs). Each CDN includes multiple edge servers that store the stream signal and manifest file until requested by a video player. When the stream signal is provided to multiple CDNs, the CDNs can be in different geographical locations, such as the West Coast, East Coast, or Midwest regions. Among other things, each video player can select a CDN based on its geographical proximity to reduce transmission latency.

[0006] A video player can be any suitable electronic device that receives the stream signal, such as a desktop computer, television, laptop computer, tablet, or mobile phone. A user initiates a request to view desired video content on the video player. The video player includes video management software executed on the video player, which has knowledge of the addresses of the CDNs and which can provide a list of the video content stored on the CDNs to the user. After the user has selected the desired video, the video player then requests that the video content be delivered from the CDN.

[0007] As further known to those skilled in the art, it is often desirable to integrate advertisements or other alternative content with the requested video content in order to, for example, generate revenue that can ultimately support the requested video content. To ensure the effectiveness of such alternative content, it is often desirable for the producer of the alternative content to require the video player to measure aspects of the alternative content being displayed. This can be done, for example, via metadata provided for commanding the video player with respect to the alternative content. Such aspects for measurement can include, for example, the precise times at which the alternative content starts, stops, and / or reaches the midpoint relative to the requested video content, the uniform resource locator (URL) address for the video player, etc. An example of a standard for communication between a server and a video player for measuring such aspects of alternative content is the Video Ad Serving Template (VAST) published by the Interactive Advertising Bureau (IAB).

[0008] In addition, as further known to those skilled in the art, it is often desirable to provide a unique viewing experience to users who are viewing the same requested video content. For example, while different users may request to view the same video content - such as a segment of a television show or movie - the users may be in completely different geographical locations and / or may have completely different viewing histories. Such differences can make the display of a particular alternative content more desirable than other alternative content. Creating a unique viewing experience for users while also ensuring the effectiveness of alternative content by measuring aspects of the alternative content being displayed presents significant technical challenges.

[0009] In addition, the owner or distributor of video content may desire to provide other information to users, such as program titles, program change information, breaking news, etc. However, such information can be geographically specific and it may not be desirable to provide the content within the video stream to all users. Other information may also not be directly available to the content provider. Instead of including such information in the video stream, triggers are embedded within the video content to alert the video player of the existence of such content. Upon receiving a trigger, the video player makes a pull request to a content server external to or out-of-band with respect to the video stream. The content server returns the appropriate content for the video player to display along with the video stream.

[0010] However, out-of-band requests made by individual video players result in the metadata being displayed at different times relative to the video content being delivered. Different video players are connected to a CDN via networks with different bandwidths, different switching devices, etc. that have variable transmission delays. Similarly, video players are connected to content servers via networks with different bandwidths, different switching devices, etc. that have variable transmission delays. Thus, the delivery of video content from the CDN and the delivery indicated by the metadata occur asynchronously, and as a result, the content indicated by the metadata cannot be displayed in synchronization with a specific frame of the video transmission. Therefore, a system that provides frame accurate playback with metadata would be desirable.

[0011] Historically, metadata has been used to a large extent to identify program productions, video clips, commercials, etc. These inserted data are based on the television model in which passive users watch video presented by content providers. However, streaming video services provide a more interactive experience. Video content can be provided on computers, mobile phones, or other devices that provide user input. Therefore, a system that provides for the insertion of interactive metadata that allows for a response from a user of the video device to be requested or solicited would be desirable. Summary of the Invention

[0012] The subject matter disclosed herein describes a method and apparatus for using a server to generate a per-user manifest file for providing a unique viewing experience and a proxy module local to a video player that receives the manifest file for measuring video playback events with frame accuracy. In one aspect, the server can be used to generate a manifest file for guiding a video player to play requested video content in a video stream along with advertisements or other potentially desired alternative content. A proxy module localized to the video player can parse the video stream to inject triggers at frame-accurate positions that may be desired for measurement, such as at precise frames where alternative content begins, stops, and / or reaches a midpoint relative to the requested video content. The proxy module can redirect the video player to the parsed and injected (modified) video stream such that the video player generates detectable events at each trigger that can be measured by the server.

[0013] Also disclosed is an apparatus or method capable of frame-accurate playback of metadata and allowing interactive metadata to be inserted in a video stream. A video manager communicates with an encoder to inject metadata in the video stream. In one embodiment, the video manager can receive triggers inserted in the video stream from a content provider and retrieve metadata corresponding to the triggers from a content server. In another embodiment, the video manager can further include a user interface operable to receive metadata from a third party. The video manager can then insert the metadata in the video stream at desired frame positions for delivery to a video player.

[0014] In one embodiment, a system for managing video playback can include: a manifest server configured to communicate with a video player and a content distribution network, the manifest server executing a program stored in a non-transitory medium and operable to: (a) receive a request from a video player for playing a video stream including requested content; (b) upon receiving the request: (i) communicate with a first content distribution network to obtain a first manifest file containing information for allowing the video player to play the requested content; and (ii) communicate with a second content distribution network to obtain information for allowing the video player to play alternative content and generate detectable events associated with the alternative content; and (c) modify the first manifest file to generate a second manifest file unique to the requesting video player, the second manifest file containing information for allowing the video player to play the requested content and alternative content and generate detectable events.

[0015] According to another embodiment, a method for managing video playback using a manifest server configured to communicate with a video player and a content distribution network may include: (a) receiving a request from a video player for playing a video stream including requested content; (b) upon receiving the request: (i) communicating with a first content distribution network to obtain a first manifest file containing information for allowing the video player to play the requested content; and (ii) communicating with a second content distribution network to obtain information for allowing the video player to play alternative content and to generate a detectable event associated with the alternative content; and (c) modifying the first manifest file to generate a second manifest file unique to the requesting video player, the second manifest file containing information for allowing the video player to play the requested content and the alternative content and to generate a detectable event.

[0016] According to another embodiment, a system for managing video playback may include: an encoder configured to convert video content from a content provider into a segmented video stream for delivery to a video player; and a video manager in communication with the encoder, the video manager executing a program stored in a non-transitory medium and operable to: (a) receive metadata for insertion into the video stream; and (b) insert the metadata at a desired frame position within the video stream.

[0017] These and other objects, advantages, and features of the present disclosure will become apparent to those skilled in the art from the following description and the accompanying drawings. However, it should be understood that, although indicating various embodiments of the present disclosure, the detailed description and the drawings are given by way of illustration and not limitation. Many changes and modifications may be made within the scope of the present disclosure without departing from its spirit, and the present disclosure includes all such modifications. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Various embodiments of the subject matter disclosed herein are illustrated in the drawings, wherein like reference numerals throughout the drawings indicate like components, and wherein:

[0019] Figure 1 is a block diagram representation of an environment including a method for measuring video playback using a manifest file generated by a server of the present disclosure;

[0020] Figure 2 is a flowchart illustrating measuring video playback using a manifest file generated by a server according to an embodiment of the present disclosure;

[0021] Figure 3A is a video signal divided into video segments, and Figure 3B is a modified video signal stitched to include alternative content segments each according to an embodiment of the present disclosure;

[0022] Figure 4A segment of a manifest file that describes the bandwidth of available streams for streaming video content and the location of each stream, according to one embodiment of the present disclosure;

[0023] Figure 5 A segment of a manifest file that includes a portion of a play list, according to one embodiment of the present disclosure;

[0024] Figure 6 A block diagram representation of an environment for delivering streaming video using a per-user manifest;

[0025] Figure 7 A flowchart illustrating per-user video manifest generation and playback; and

[0026] Figure 8 A screenshot of a user interface executed on a video manager for selecting metadata to insert into a video stream, according to one embodiment of the present disclosure.

[0027] In describing various embodiments of the present disclosure illustrated in the drawings, specific terms are used for the sake of clarity. However, the present disclosure is not intended to be limited to the specific terms so chosen, and it should be understood that each specific term includes all technical equivalents that operate in a similar manner to accomplish a similar purpose. For example, the words "connected," "attached," or terms similar thereto are often used. It is not limited to direct connection but includes connection through other elements, where such connection is considered equivalent by those skilled in the art. Detailed Description

[0028] The various features and advantageous details of the subject matter disclosed herein are explained more fully with reference to the non-limiting embodiments described in the following description.

[0029] First, look at Figure 1 , which illustrates an environment for measuring video playback using a manifest file generated by a server. A content provider 110 generates a video signal 112 to be distributed to video consumers. The video signal can be provided in an uncompressed file format such as SDI format or in a compressed format such as MPEG or TS file format. The video signal 112 is sent to an encoder 114, which converts the file into a live stream signal 116. The live stream signal 116 is preferably a segmented data stream that can be transmitted over the Internet using standard HTTP or HTTPS protocols. The live stream signal 116 can include multiple streams, where each stream can have a different data rate and / or different resolution. The format of the live stream signal can be, but is not limited to, HLS or MPEG-DASH. Such as from or Other protocols such as Smooth Streaming and HTTP Dynamic Streaming (HDS) may be used without departing from the scope of the present disclosure.

[0030] In addition to the segmented data stream, the encoder generates a manifest file. The manifest file contains information for a playback manifest for the video player 122 to play the segmented data stream and provide addresses from which the video content can be retrieved, such as the data rate and resolution of each stream. The encoder 114 generates a single manifest file for each encoded video signal, where the manifest file is distributed along with the stream signal 116 and stored on the CDN 118. Each CDN 118 includes a plurality of edge servers 120 that store the encoded video signal 116 and the manifest file until playback of the video content is requested by the video player 122. Although the illustrated embodiment in Figure 1 shows a single CDN 118, it should be anticipated that the encoded video signal 116 can be stored on multiple CDNs 118. The manifest file can include the addresses of each CDN such that playback can occur from any of the CDNs 118.

[0031] As further illustrated in Figure 1 the environment includes a manifest server 124. The manifest server 124 is used to provide a unique manifest file - also referred to herein as a per-user manifest file - to each video player 122 for each requested video content. Each video player 122 includes a native video player module 128 that provides an interface to the user and that manages video playback on the video player 122. Each video player 122 also includes a proxy module 129. The proxy module 129 can be a plug-in or other software module executed on the video player 122 that supplements (i.e., adds additional capabilities) or replaces (i.e., adds additional capabilities and includes video interface and playback capabilities) the native video player module 128. As will be described in more detail below, in one aspect, when the user 125 requests video content for playback on the video player 122, the native video player module 128 can communicate with the proxy module 129 and thus with the manifest server 124 (instead of the CDN 118) to obtain the manifest file for video playback. The manifest server 124 manages the retrieval and delivery of the manifest file generated by the encoder 114 to provide a unique manifest file to each video player 122.

[0032] As further illustrated in Figure 1 the environment may also include one or more alternative content networks (ACNs) 123 and / or alternative content measurers 127. Alternative content such as commercials can be stored in the ACN 123. Although inFigure 1 The illustrated embodiment shows a single ACN 123, but it should be anticipated that alternatives may be stored on multiple ACNs 123 in different geographical locations. Each ACN 123 may include a number of edge servers 121, which may store stream signals for alternative content until requested by the manifest server 124. Among other things, the manifest server 124 may select an ACN 123 based on its geographical proximity to reduce transmission latency. The alternative content measurer 127 may communicate with the video player 122 for measuring detectable events reported by the video player 122 in the video stream, such as triggers for alternative content injection relative to the measurement server.

[0033] Then go to Figure 2 , which illustrates the operations performed for video playback using a manifest file generated by the server. At block 130, the encoder 114 receives the initial video signal 112. It should be anticipated that the video signal 112 may be a prerecorded signal, such as a segment of a television program or movie, or the video signal 112 may be a live stream of, for example, a sports event, concert, or news feed. The encoder 114 converts the raw video signal into a live stream signal 116 suitable for delivery via (one or more) HTTP. One operation in converting the video signal is to divide the video signal into segments. The segments may be, for example, 10 seconds in length. Optionally, other segment lengths, such as from 1 second up to 10 seconds, may be selected. The length of the video segments must be less than the maximum payload for HTTP data packets. Simply referring to Figure 3A , the video signal 116 from the encoder 114, shown by way of example, may consist of video content divided into nine segments of the requested video content, illustrated as "c1", "c2", "c3", etc., each segment being 10 seconds in length for a net content length of 90 seconds. After generating the video signal 116 as segments (also referred to as the requested video content), the video signal and the manifest file are transmitted to the CDN 118 for storage in one of the edge servers 120, as shown in block 132.

[0034] At block 134, the user 125 then requests playback of the desired video segment on the video player 122 via the native video player module 128. The video player 122 may be any suitable electronic device that receives the stream signal 116, such as a desktop computer, television, laptop computer, tablet, Wi-Fi-enabled device connected to a video screen, or mobile phone. At block 136, the native video player module 128 then requests the manifest file from the proxy module 129 in order to retrieve the information necessary to play the requested video content.

[0035] At block 138, the proxy module 129 then requests a manifest file from the manifest server 124. When the video player 122 requests a manifest file from the manifest server 124, a connection is established between the devices. A session identifier can also be generated to identify the connection. The session identifier can be generated by the video server 122 or the manifest server 124. For illustrative purposes, it can be assumed that the session identifier can be generated by the video player 122. When requesting the manifest file, the session identifier can be transmitted by the video player 122 to the manifest server 124.

[0036] Since the manifest server 124 has established a connection with the video player 122, it can customize the manifest file before returning the manifest file to the video player 122 and provide a unique manifest file to each video player 122. In the absence of the manifest server 124, the video player 122 directly retrieves the manifest file from the CDN 118 and the content of the manifest file is the same for all users. However, since the manifest server 124 provides a unique manifest file to each player, the manifest file can include identification information of the video player 122, the user 125 of the video player, or a combination thereof. Further, the manifest file can be modified to include content specific to the user 125.

[0037] At block 140, the manifest server 124 communicates with the ACN 123 to request alternative content that can be applied to the user 125 and / or the video player 122. Among other things, such alternative content can depend, for example, on the geographical location and / or viewing history of the user 125 and / or the video player 122. The alternative content can be used, for example, to provide advertisements or other alternative content at the start or end of the requested video content or during an interruption segment. The manifest server 124 can request alternative content from the ACN 123 for each user session and for each display opportunity. At block 142, the ACN 123 returns the alternative content, which can ultimately be stitched into the video stream for the video player 122.

[0038] To ensure the effectiveness of the alternative content, the alternative content can include a payload (alternative content payload information) containing specific event triggers and / or a request for corresponding user session-specific data for measuring the alternative content at the video player 122. This can be done, for example, via metadata provided with the alternative content that commands the video player 122 to react. Such event triggers can include, for example, reacting at the exact time when a frame of the alternative content is relative to the start, stop, and / or reaching the midpoint of the requested video content, in response to a URL address for the video player 122, etc.

[0039] Then, at block 144, the manifest server 124 communicates with the CDN 118, and at block 146, the most recent manifest file corresponding to a particular user's request is loaded from the CDN 118. The manifest server 124 may periodically load updates to the manifest files from the CDN 118 as may be required. At block 146, the CDN 118 provides the manifest file and / or updates to the manifest server 124. In turn, the manifest server 124 processes the manifest file from the CDN 118 to determine suitable locations for stitching alternative content. In one aspect, such locations may be pre-determined by the encoder 114 in the manifest file.

[0040] Accordingly, the manifest server 124 updates the manifest file to include alternative content segments in the video stream as appropriate. For example, simply referring to Figure 3B , with the generated customized manifest file, the video signal 116 can be reconfigured for playback as a modified video signal 116' that includes two segments of alternative content, illustrated as "a1" and "a2", followed by four segments of the requested video content, illustrated as "c1", "c2", "c3", and "c4", followed by another two segments of alternative content, illustrated as "a2" and "a3", and then followed by another four segments of the requested video content, illustrated as "c5", "c6", "c7", and "c8". In the case where the segments are 10 seconds in length, the modified video signal 116' can then have a total content length of 130 seconds. The stitched video stream can reflect the implementation of, for example, logical rules by the manifest server 124 that requests an initial viewing of a first advertisement and a mid-stream viewing of a second advertisement for the first viewing of the requested video content at the video player 122. Each time the user 125 plays the video, the video player 122 can obtain an updated manifest file from the manifest server 124. The manifest server 124 can individually measure the state of the video player 122 and the user viewing experience.

[0041] Also referring to Figure 4 and Figure 5 , segments of the manifest file are illustrated that show a portion of the content that may be available in the manifest file. The manifest file is a text file and the specific content on each line of the text file is identified by an indication at the start of the line. For example, Figure 4 identifies different streams in the stream new signal 116, where each stream has a different bandwidth. The locations of the playback manifests for each stream are also included in the manifest file. Figure 5Another manifest file that is part of a playlist containing video segments. Each line can identify a specific video segment between 1 and 5 (i.e., "-1", "-2", etc. before the.ts file extension) and provide the location of the video segment in CDN 118. The manifest file can include any information corresponding to the video stream, such as metadata information for the video stream.

[0042] In addition, while the segments of the manifest file are updated to provide alternative content, the aforementioned alternative content payload for measurement can also be added to the manifest file. Referring again to Figure 2 , at block 148, the manifest server 124 transmits the updated manifest file to the proxy module 129.

[0043] Then, at block 150, the proxy module 129 parses the updated manifest file and extracts the alternative content payload information for measurement and stores the information in memory. The proxy module 129 then determines the frame position at the start of each alternative content segment. Thus, the proxy module 129 can modify the video stream using the updated manifest file, such as by replacing the video segments (TS file locations) in the manifest file with the proxy locations (TS proxy file locations) of the video segments provided by the proxy module 129. Thus, when the video player 122 makes a request for the video stream, the video segments at the proxy locations can be provided. In addition, when replacing video segments, the alternative content payload information for measurement - including metadata, location information, etc. or references to such information - can also be included. The newly updated manifest file manipulated by the proxy module 129 using the video segments at the proxy locations is then sent to the native video player module 128.

[0044] At block 152, when receiving the manifest file in accordance with its request, the native video player module 128 can then request video segment display. Since the manifest file now includes the proxy locations for the video segments, the native video player module 128 will request the video segments from the proxy module 129.

[0045] At block 154, the proxy module 129 communicates with the CDN 118 to request video content segments; and at block 156, the proxy module 129 loads the video content segments from the CDN 118. Before the video content segments are sent to the native video player module 128, the proxy module 129 may repackage the video content segments with alternative content segments and may inject frame-accurate triggers - such as according to the ID3 standard for metadata - to form a video stream. These triggers may be set to measure alternative content segments with alternative content payload information, or references to alternative content segments, by triggering on events such as the start, stop, and / or midpoint frames of the display of alternative segments in the video player 122. Thus, the proxy module 129 may load a video stream (TS file) with video content segments, alternative content segments, and frame-accurate triggers corresponding to the alternative content payload information.

[0046] At block 158, the proxy module 129 provides the video stream to the native video player module 128, which in turn plays the video stream to the user 125. During playback, the video player 122 will trigger on the predetermined frame triggers that have been injected according to the alternative content payload information. These triggers may result in detectable events that may be measured by a server for measuring information about the video player 122 playing the video stream.

[0047] At block 160, the video player 122 may play the video stream for the user 125 via the native video player module 128. The user 125 may in turn also interact with the video player 122, such as seeking forward or backward in the video stream, requesting new video content, etc. Additionally, at block 162, when the video stream is being played, the video player 122 may trigger via the proxy module 129 on a detectable event - such as a frame-accurate trigger corresponding to the alternative content payload content. Such detectable events may be measured by one or more servers or other entities - such as the alternative content measurer 127.

[0048] Then go to Figure 6 , according to another aspect of the present disclosure, the content provider 210 generates a video signal 212 to be distributed to video consumers. The video signal may be provided in an uncompressed file format such as the SDI format or in a compressed format such as the MPEG or TS file format. The video signal 212 is sent to an encoder 214, which converts the file into a live stream signal 216. The live stream signal 216 is preferably a segmented data stream that can be transmitted over the Internet using standard HTTP or HTTPS protocols. The live stream signal 216 may include multiple streams, where each stream may have a different data rate and / or different resolution. The format of the live stream signal may be, but is not limited to, HLS or MPEG-DASH. However, such as from Or Other protocols such as HTTP Dynamic Streaming (HDS) of Smooth Streaming can be used without departing from the scope of the present disclosure.

[0049] In addition to the segmented data stream, the encoder generates a manifest file. The manifest file contains information for a playback manifest for a video player to play the segmented data stream and provide an address from which the video content can be retrieved, such as the data rate and resolution of each stream. The encoder 214 generates a single manifest file for each encoded video signal, where the manifest file is distributed together with the stream signal 216 and stored on the CDN 218. It should be noted that the "single" manifest file refers to a common or identical manifest file for each encoded signal. The manifest file can include multiple data files stored on the CDN, where each manifest file contains a portion of the data required to playback the stream signal. Further, for live stream video, when new content is added from a live event, the manifest file can be updated and retransmitted at periodic intervals. Although multiple files are used, the content generated by the encoder 214 for delivery to each video player 222 is the same. Each CDN 218 includes a number of edge servers 220 that store the encoded video signal 216 and the manifest file until the playback of the video content is requested by the video player 222. Although the embodiment illustrated in Figure 6 shows a single CDN 218, it should be anticipated that the encoded video signal 216 can be stored on multiple CDNs 218. The manifest file can include the addresses of each CDN such that playback can occur from any of the CDNs 218.

[0050] As further illustrated in Figure 6 the exemplary environment includes a manifest server 224. The manifest server 224 is used to provide a unique manifest file - also referred to herein as a per-user manifest file - to each video player 222 for each requested video content. Each video player 222 includes a native video player module 228 that provides an interface to the user and that manages video playback on the device 222. Some video players 222 may also include what is illustrated as Figure 6The enhanced video player module 229 of the optional module in []. The enhanced video player module 229 can be a plug-in or other software module executed on the video player 222, which supplements (i.e., adds additional capabilities) or replaces (i.e., adds additional capabilities and includes a video interface and playback capabilities) the native video player module 228. As will be described in more detail below, when the user 225 requests video content for playback on the video device 222, the native or enhanced video player module 229 communicates with the manifest server 224 instead of the CDN 218 to obtain the manifest file for video playback. The manifest server 224 manages the retrieval and delivery of the manifest files generated by the encoder 214 to provide a unique manifest file to each video player 222.

[0051] The exemplary embodiment also includes a video manager 215 that communicates with the encoder 214. The video manager 215 receives triggers included in the video signal 212 from the content provider. The video manager 215 also communicates with the content server 217 and the manifest server 224, where the content server 217 may store the metadata generated by the content provider 210 and which was previously retrieved by the video player 222 via an out-of-band method. According to one embodiment of the present disclosure, the video manager 215 and the manifest server 214 are implemented on a single server. According to another embodiment of the present disclosure, the video manager 215 and the manifest server 224 are implemented on a single server. Since the manifest server 224 has established a per-user connection with each video player 222, as discussed in more detail below, the video manager 215 is able to identify the content intended for a particular video player 222 based on the per-user connection. Upon detecting a trigger in the video signal 212, the video manager 215 contacts the content server 217 to retrieve the metadata corresponding to the trigger that would otherwise need to be requested out-of-band by the video player 222. The metadata may be common to all video players 222 or may be tailored, for example, for a geographic region or a particular video player 222. Having retrieved the information, the video manager communicates the information to the encoder 214, where it may be included in the transport stream for direct delivery to the video player. Inserting the information into the video stream is discussed in more detail below.

[0052] Then go to Figure 7, which illustrates the operations performed to create, deliver, and playback a per-user manifest file. At block 230, the encoder 214 receives an initial video signal 212. It should be anticipated that the video signal 212 can be a prerecorded signal - such as an episode of a television show or a movie or the video signal 212 can be a live stream of, for example, a sports event, a concert, or a news feed. The encoder 214 converts the raw video signal into a live stream signal 216 suitable for delivery via one or more HTTPs. One operation in converting the video signal is to divide the video signal into segments. The segments can be, for example, 10 seconds in length. Optionally, other segment lengths can be chosen, for example, from 1 second up to 10 seconds. The length of the video segments must be less than the maximum payload for an HTTP data packet.

[0053] After converting the video signal 212 into segments, the encoder 214 can encrypt the video signal 212 to prevent unauthorized viewing of the video content. At block 232, the encoder 214 establishes communication with the key server 226 and requests a key for encrypting the segmented video signal 212. The key server 226 returns the key to the encoder 214, as shown at block 234. The key used to encrypt the segmented video signal 212 will be referred to herein as the content encryption key. The encoder 214 can use any suitable encryption protocol, such as the Advanced Encryption Standard (AES), to encrypt the segmented video signal using the content encryption key. The location of the key server and the encryption key used to encrypt the segmented video signal are included in the manifest file. The manifest file and the encrypted video signal are then transmitted to the CDN 218 for storage in one of the edge servers 220, as shown at block 236.

[0054] At block 238, the user 225 then requests playback of a desired video segment on the video player 222. The video player 222 can be any suitable electronic device that receives the stream signal 216, such as a desktop computer, a television, a laptop computer, a tablet, a Wi-Fi-enabled device connected to a video screen, or a mobile phone. The video player 222 requests the manifest file from the manifest server 224 in order to retrieve the information necessary to play the requested video content. Referring again to Figure 4 and Figure 5 , which illustrates a segment of an exemplary manifest file that illustrates a portion of the content that can be available in the manifest file. The manifest file is a text file and the specific content on each line of the text file is identified by an indication at the start of the line. For example, Figure 4 identifies the different streams in the stream signal 216, where each stream has a different bandwidth. The location of the playback manifest for each stream is also included in the manifest file. Figure 5Another manifest file that is part of a playlist containing encrypted video segments. Each line starts with the location of the key server to decrypt the video segment, identifies a specific video segment between 1 and 5 (i.e., "-1", "-2", etc. before the.ts file extension), and provides the location of the video segment in the CDN 218. The manifest file can include any information corresponding to the video stream, such as metadata information for the video stream.

[0055] When the video player 222 requests the manifest file from the manifest server 224, a connection is established between the devices. A session identifier is also generated to identify the connection. The session identifier can be generated by the video server 222 or the manifest server 224. For illustrative purposes, it will be assumed that the session identifier is generated by the video player 222. When requesting the manifest file, the session identifier is transmitted by the video player 222 to the manifest server 224. At block 242, the manifest server 224 then requests the manifest file from the CDN 218. At block 244, the CDN 218 returns the manifest file to the manifest server 224.

[0056] Since the manifest server 224 has established a connection with the video player 222, it can customize the manifest file and provide a unique manifest file to each video player 222 before returning the manifest file to the video player 222. In the absence of the manifest server 224, the video player 222 retrieves the manifest file directly from the CDN 218 and the content of the manifest file is the same for all users. However, since the manifest server 224 provides a unique manifest file to each player, the manifest file can include identification information of the video player 222, the user 225 of the video player, or a combination thereof. Further, the manifest file can be modified to include content specific to the user 225.

[0057] The manifest server 224 can be configured to generate an encryption key for each manifest file. The encryption key is generated based on the unique session identifier generated by the video player 222 when it requests the desired video content. Optionally, the encryption key can also be generated as a function of the requested video content. Thus, each encryption key is unique for a specific session with a specific video player, which results in a one-time use unique encryption key. The one-time use unique encryption key will be referred to herein as the manifest encryption key. At block 246, the manifest server 224 transmits the manifest encryption key to the key server 226, and at block 248, the key server 226 acknowledges the receipt of the manifest encryption key.

[0058] Optionally, the key server 226 may be configured to generate a manifest encryption key. At block 246, the manifest server 224 transmits the session identifier and the identifier corresponding to the desired video content to the key server instead of transmitting the manifest encryption key. The key server 226 may then generate the manifest encryption key, and at block 248, return the manifest encryption key to the manifest server 224. After generating or obtaining the manifest encryption key, the manifest server 224 encrypts the manifest file before transmitting the manifest file to the video server 222. The manifest server 224 then transmits the encrypted manifest file to the video player 222, as shown at block 250.

[0059] Referring again to Figure 6 , if the video player 222 includes an enhanced video player module 229 from the provider of the manifest server 224, the enhanced video player module 229 may be configured to directly decrypt the encrypted manifest file. The manifest encryption key is encrypted in a manner known to both the manifest server 224 and the enhanced video player module 229. Thus, the enhanced video player module 229 first decodes the manifest encryption key and then uses the manifest encryption key to decode the remainder of the manifest file. However, if the video player does not include an enhanced video player module 229 from the provider of the manifest server 224, the manifest server 224 may include a path to the key server 226, similar to that shown in Figure 5 , and the video player 222 requests the manifest encryption key from the key server 226, as shown at block 252. At block 254, the key server 226 returns the manifest encryption key to the video player 222, and the video player 222 decrypts the manifest file. Having decrypted the manifest file, either directly on the video player 222 with the enhanced video player module 229 or by requesting the manifest encryption key from the key server 226 and then decoding the manifest file with the native video player module 228, the enhanced video player module 229 or the native video player module 228 then needs to decode the video content.

[0060] In some embodiments, the manifest file may remain unencrypted. When the manifest file remains unencrypted, the manifest server 224 may still generate a unique manifest file for the session with the video player 222. Figure 7 The operations in

[0061] The video player module reads the location of the key server 226 for the content encryption key from the manifest file. It should be anticipated that a single key server 226 can contain both the manifest encryption key and the content encryption key. Optionally, separate key servers 226 can be used for each of the encryption keys. The video player 222 requests the content encryption key from the key server 226 identified in the manifest file, as shown in block 256. At block 258, the key server 226 returns the content encryption key to the video player 222. The manifest file will have the address of the CDN 218 as containing the segmented video content. Thus, the video player is then able to start retrieving the video content from the CDN. The video player 222 repeatedly requests the next segment in the play manifest from the CDN 218 and the CDN returns the requested segment, as shown in blocks 260 and 262. The native video player module 228 then decodes the content from the encrypted video segment and displays the requested video content to the user 225.

[0062] Then go to Figure 8 A user interface 300 can be provided that executes on the video manager 215. The user interface 300 receives input corresponding to desired controls or actions taken on the video player when the video content is being presented to the video player 222. The user interface 300 includes a frame viewer that displays the video content on a frame-by-frame basis to synchronize metadata with a particular frame of the video content. The user interface 300 also includes an event selector 320 that identifies the desired actions to be taken on the video player 222. The selected events are encoded as metadata, for example, as ID3 tags for insertion into the video stream.

[0063] Video players 222 are increasingly being used as interactive devices - such as laptops or tablet computers, mobile phones, etc. - rather than as passive viewing devices - such as traditional televisions. The video player 222 can include many native applications, such as a calendar application, a web browser, or a social media plugin. The events selected for inclusion as metadata can activate one of the native applications for an enhanced viewer experience. For example, a programming change can initiate the calendar application and create an appointment for the calendar. The appointment can identify the new time for the program with a prompt to the viewer that allows the viewer to accept the appointment for insertion into their calendar. As another example, the selected event can initiate a web browser with a window providing additional content, such as a list of links to the program website or websites on a topic related to the documentary. The viewer can choose to follow one of the presented links. As yet another example, the event can initiate a social media plugin that allows the user to indicate whether they liked the program or provide a review of the program on their social media account.

[0064] According to another aspect of the present disclosure, the metadata can be related to an advertisement. Instead of simply an advertisement to be displayed on the video player 222, the advertisement can be interactive, requiring the viewer to click on one or more boxes, buttons, etc. within the advertisement. The prompts to the viewer need to be displayed within the correct frame of the advertisement so that the viewer understands what is being requested. Optionally, the prompts can request the viewer to select one of multiple advertisements for viewing, distributing more appealing content to the viewer. The metadata can also include instructions to the video player 222 to transmit the viewer interaction back to the user interface 300 for measurement.

[0065] According to yet another aspect of the present disclosure, the metadata can be related to the content of a program production. For example, a viewer may want to watch a live sports event. However, many replay rules can be in place with respect to the event. The replay rules can include, for example, geographical blackout restrictions or geographical transmissions for a particular event such as a local team. The live sports event can run less than its scheduled time or exceed its original time period. When the replay rules may have been initially transmitted according to the original schedule, the rules may need to be updated, for example, to force a blackout beyond the schedule when the event runs long or to allow an alternative program to be viewed if the event runs short or is cancelled due to weather, for example. Additionally, it is desirable to force the rules at a particular frame to provide a clear transition to or from the live event and the alternative program.

[0066] According to yet another aspect of the present disclosure, the metadata can be inserted within a transport stream (TS) file that contains video content. When the encoder 214 receives the video signal 212 from the content provider 210, any triggers inserted within the video signal 212 by the content provider 210 are detected. The video manager 215 receives the triggers and identifies the metadata content corresponding to the triggers. The video manager 215 retrieves the video content from the content server 217. Optionally, the video manager 215 receives the metadata and frame references from the user interface 300. The video manager 215 can encode the metadata according to the requirements of the transport stream into which it is being inserted, or the video manager 215 can transmit the metadata to the encoder 214 where it is encoded. The transport stream includes a metadata stream that includes the content of the metadata (e.g., displayed text or graphics, launched applications, replay rules, etc.) and the frame at which the metadata will be displayed or activated. The metadata is then transmitted within the transport stream to the video player 222, as discussed above.

[0067] In yet another aspect of the present disclosure, metadata is inserted into a manifest file for transmission to a video player. The video manager 215 receives a trigger from the video signal 212 or metadata from the user interface 300, as previously discussed. Custom tags are defined for insertion into the manifest file. The custom tags include the content of the metadata and a frame reference at which the metadata will be displayed or activated. The custom tags are inserted into the playlist of the manifest file and transmitted to the video player 222, as discussed above. Inserting the custom tags into the manifest file can occur using the encoder 214 or using the manifest server 224. According to one embodiment, when the video signal 212 is being encoded, the video manager 215 transmits the custom tags to the encoder 214. The custom tags are inserted into the manifest file generated by the encoder 214 and stored in the CDN 218. The manifest server 224 initially reads the manifest file from the CDN before generating the per-user manifest file, and thus, the custom tags will be in the manifest file. According to another embodiment, the metadata can be provided at delivery rather than when the original video stream is encoded. The custom tags can be transmitted from the video manager 215 to the manifest server 224 and inserted into the per-user manifest file by the manifest server 224.

[0068] The video player 222 receives a transport stream and a manifest file for the requested video content into which the manifest data has been inserted. A native video player module 228 or an enhanced video player module 229 can be used to extract or act on the embedded metadata. If, for example, the metadata is inserted into the transport stream, the native video player module 228 receives the transport stream and processes the metadata. However, instead of receiving only a trigger, the transport stream includes the metadata content and the video player 222 can take the requested action without requiring an out-of-band connection. Similarly, if the metadata is inserted into a manifest file with custom tags, the enhanced video player module 229 identifies the tags and creates a metadata stream within the video player 222. The enhanced video player module 229 inserts the metadata stream into the transport stream at the correct frame position. Regardless of whether the metadata is inserted into the transport stream or the manifest file, the requested action occurs on the video player 222 at the desired frame of the video content without requiring an out-of-band connection to retrieve the content.

[0069] In one aspect of the present disclosure, a method is provided to insert per-user per-session metadata for advertising or other alternative content received from an alternative content server for a particular user session (for measurement) into a manifest file for delivery to a video player of a user.

[0070] According to another aspect of the present disclosure, a method is provided for creating frame-accurate triggers in a video transport stream from metadata injected into a manifest file by a per-user manifest delivery system (manifest server). This can allow a video player to utilize each metadata trigger event with per-frame accuracy, such as providing a notification to a server.

[0071] According to another aspect of the present disclosure, a method is provided for a user to interact with an advertisement or other alternative content (which can be stitched together with the requested video content) using metadata triggers and actions that can be guided by such metadata triggers. In one aspect, the action can include retrieving information when the user can trigger an action by clicking on the alternative content when it is displayed.

[0072] According to another aspect of the present disclosure, a method is provided for measuring an advertisement or other alternative content in a live stream stitched by a server using frame-accurate triggers inserted by the system.

[0073] According to another aspect of the present disclosure, a system is provided that can solve the problem of accurately measuring an advertisement or other alternative content when the advertisement or other alternative content is stitched together by a separate server (in which case, the video player only receives the video file and does not measure the information embedded in the original advertisement or other alternative content).

[0074] According to another aspect of the present disclosure, a hardware or software module can be implemented in a video player to: process a unique video manifest file loaded from a manifest server; parse the manifest file, which contains alternative content measurement information; process the manifest file to obtain the total net time for each alternative content segment; and inject measurement capabilities into the video stream (TS file) for the alternative content measurement information via frame-accurate triggers. In this way, a modified video stream (TS file) is provided to the video player, which can allow the video player to trigger to generate a detectable event that can be measured by a server or other entity at a desired time.

[0075] It should be understood that the present disclosure is not limited in its application to the details of the construction and arrangement of the components set forth herein. The present disclosure is capable of other embodiments and of being practiced or carried out in various ways. Variations and modifications of the foregoing are within the scope of the present disclosure. It should also be understood that the present disclosure, as disclosed and defined herein, extends to all alternative combinations of two or more of the individual features mentioned or evident from the text and / or drawings. All such different combinations constitute various alternative aspects of the present disclosure. The embodiments described herein illustrate the best mode known for practicing the present disclosure and will enable those skilled in the art to utilize the present disclosure.

Claims

1. A system for managing video playback, comprising: An inventory server, the inventory server including a memory and a processing device coupled to the memory, for: (a) Receiving a request from a video player on a user device to play a video stream including the requested content, wherein the requested content is associated with a first manifest file, the first manifest file being created for the requested content and distributed to a first content delivery network; (b) When receiving the request: (i) Communicating with the first content delivery network to obtain from the first content delivery network the first manifest file stored at the first content delivery network, the first manifest file containing information for allowing the video player to play the requested content stored at the first content delivery network and information for stitching alternative content with the requested content; and (ii) Communicating with a second content delivery network to obtain information for allowing the video player to play the alternative content and generate a detectable event related to the alternative content; (c) Using a session identifier identifying the connection between the inventory server and the video player, modifying the first manifest file obtained from the first content delivery network to generate a second manifest file, the second manifest file being unique to the video player having the request, the second manifest file identifying at least one of the video player or the user of the video player, and containing information for allowing the video player to play the requested content and the alternative content stitched with the requested content and generate the detectable event related to the alternative content, wherein the detectable event associated with the alternative content is detectable during the video stream of the user's video player and can be distinguished from detectable events associated with other users.

2. The system according to claim 1, wherein, The detectable event is generated by a trigger.

3. The system according to claim 2, wherein, The processing device is used to command the video player to make a response based on the trigger, the trigger occurring in response to the start or stop of a frame of the alternative content.

4. The system according to claim 2, wherein, The processing device is used to command the video player to make a response based on the trigger, the trigger occurring in response to the alternative content reaching the midpoint.

5. The system according to claim 1, wherein, The inventory server stitches segments of the alternative content between segments of the requested content according to the second manifest file.

6. The system according to claim 1, wherein, The second manifest file includes the session identifier.

7. The system according to claim 1, further comprising a measurement server communicating with the inventory server, wherein the measurement server stores the detectable event.

8. The system according to claim 1, wherein, The detectable event associated with the alternative content is defined via metadata provided for the alternative content, and wherein the metadata defining the detectable event associated with the alternative content is included in the playlist of the second manifest file.

9. The system according to claim 8, wherein, the playlist provides an address and at least one of a data rate and a resolution for the video stream that will be retrieved at the address.

10. The system according to claim 1, wherein the processing device is further configured to: encrypt the second manifest file using an encryption key generated based on the session identifier before transmitting the second manifest file to the video player.

11. A method for managing video playback, the method comprising: (a) receiving, from a video player on a user device, a request to play a video stream including requested content, wherein the requested content is associated with a first manifest file that is created for the requested content and distributed to a first content delivery network; (b) upon receiving the request: (i) communicating with the first content delivery network to obtain the first manifest file stored at the first content delivery network from the first content delivery network, the first manifest file including information for allowing the video player to play the requested content stored at the first content delivery network and information for stitching alternative content with the requested content; and (ii) communicating with a second content delivery network to obtain information for allowing the video player to play the alternative content and to generate a detectable event related to the alternative content; (c) modifying the first manifest file obtained from the first content delivery network using a session identifier identifying a connection between the manifest server and the video player to produce a second manifest file that is unique to the video player having the request, the second manifest file identifying at least one of the video player or the user of the video player, and including information for allowing the video player to play the requested content and the alternative content stitched with the requested content and to generate the detectable event related to the alternative content, wherein the detectable event associated with the alternative content is detectable during a video stream of the user's video player and is distinguishable from detectable events associated with other users.

12. The method according to claim 11, wherein, the detectable event is generated by a trigger.

13. The method according to claim 12, further comprising: commanding the video player to respond based on the trigger, the trigger occurring in response to the start or stop of a frame of the alternative content.

14. The method according to claim 12, further comprising: commanding the video player to respond based on the trigger, the trigger occurring in response to the alternative content reaching a midpoint.

15. The method according to claim 11, further comprises: stitching segments of the alternative content between segments of the requested content according to the second manifest file.

16. The method according to claim 11, wherein, the second manifest file includes the session identifier.

17. The method according to claim 11, further comprises: communicating with a measurement server storing the detectable event.

18. The method according to claim 11, wherein, the detectable event associated with the alternative content is defined via metadata provided for the alternative content, and the metadata defining the detectable event associated with the alternative content is included in a playlist of the second manifest file.

19. The method according to claim 18, wherein, the playlist provides an address and at least one of a data rate and a resolution for the video stream that will be retrieved at the address.

20. The method according to claim 11, further comprises: encrypting the second manifest file using an encryption key generated based on the session identifier before transmitting the second manifest file to the video player.

21. A non-transitory computer-readable medium including instructions that, when executed by a processing device, cause the processing device to perform operations, the operations comprise: (a) receiving, from a video player on a user device, a request to play a video stream including requested content, wherein the requested content is associated with a first manifest file that is created for the requested content and distributed to a first content delivery network; (b) upon receiving the request: (i) communicating with the first content delivery network to obtain the first manifest file stored at the first content delivery network from the first content delivery network, the first manifest file including information for allowing the video player to play the requested content stored at the first content delivery network and information for stitching alternative content to the requested content; and (ii) communicating with a second content delivery network to obtain information for allowing the video player to play the alternative content and generate a detectable event related to the alternative content; (c) modifying the first manifest file obtained from the first content delivery network using a session identifier identifying a connection between the manifest server and the video player to produce a second manifest file that is unique to the video player having the request, the second manifest file identifying at least one of the video player and the user of the video player, and including information for allowing the video player to play the requested content and the alternative content stitched to the requested content and generate the detectable event related to the alternative content, wherein the detectable event associated with the alternative content is detectable during a video stream of the user's video player and is distinguishable from detectable events associated with other users.

22. The non-transitory computer-readable medium according to claim 21, wherein, the detectable event is generated by a trigger.

23. The non-transitory computer-readable medium according to claim 22, wherein the operation further comprises: commanding the video player to respond based on the trigger, the trigger occurring in response to the start or stop of a frame of the alternative content.

24. The non-transitory computer-readable medium according to claim 22, wherein the operation further comprises: commanding the video player to respond based on the trigger, the trigger occurring in response to the alternative content reaching a midpoint.

Images