US8887215B2 - Targeted high-value content in HTTP streaming video on demand - Google Patents

Abstract

Methods and apparatus are provided for combining assets for a streaming video signal. Video assets are provided in an adaptive bit rate format. The video assets may comprise fragments of various types of video content. A stitched manifest identifying a combination of the video assets is created in response to a client request for one or more of the video assets. The stitched manifest is provided to a client and used by the client to request the combination of video assets for playback as one continuous video stream in an order specified by the stitched manifest.

Description

This application claims the benefit of U.S. Provisional Patent Application No. 61/658,036, filed Jun. 11, 2012, which is incorporated herein and made a part hereof by reference.

BACKGROUND OF THE INVENTION

The present invention relates to the delivery of video content, such as advertisements or movies, to users using HTTP streaming with multiple high-value features, including efficient load-balancing, user-specific watermarking, and Uniform Resource Locator (URL) obfuscation.

The explosion of streaming video on Internet Protocol (IP) networks has led to the development of so-called Adaptive Hypertext Transfer Protocol (HTTP) Streaming protocols for video (also referred to as “adaptive bit rate” formats). While there are multiple instantiations of these protocols, they share the following features: (a) a video stream is broken into short, several-second-long files which are downloaded by a client and played sequentially to form a seamless video view; (b) these files, or “fragments” of video content, may be encoded at different bit rates and resolutions (referred to as “profiles”) to provide several versions of each fragment; (c) a manifest file is used to identify the fragments and let the client know the various available profiles, so that it can select which fragments to download based on local conditions, such as the available download bandwidth; and (d) in a typical scenario, the client may start downloading fragments at low resolution and low bandwidth and then switch to downloading fragments from higher bandwidth profiles, giving the user a fast tune-in experience and subsequent better video quality experience.

In a video-on-demand (VOD) scenario, the fragments from different profiles may be stored on disk or other mass storage devices for delivery via HTTP, but this forces video programs (also referred to herein as “assets”) to be composed of many separate files, which complicates content management. Thus, the fragments can be stored in a single aggregated file from which they are extracted “just-in-time” (JIT) when a client makes a request for a specific fragment.

The leading HTTP streaming formats in use currently are Apple® HTTP Live Streaming (HLS), Microsoft® Smooth Streaming (MSS), Adobe® HTTP Dynamic Streaming (HDS), and MPEG Dynamic Adaptive Streaming over HTTP (DASH). A just-in-time Packager (JITP) is a process that enables extraction of fragments from an aggregated collection (or a mezzanine file) and distribution of the extracted fragments over HTTP in these or other HTTP streaming formats.

A normal JITP can serve files from a single asset, but it cannot serve a collection of assets contiguously in response to one VOD request. It would be advantageous to provide a system in which a collection of assets can be served contiguously in response to one VOD request, whether coming from a JITP or from other origins. It would be further advantageous to provide methods for contiguously serving a collection of assets to a client in response to a single VOD request.

The methods and apparatus of the present invention provide the foregoing and other advantages.

SUMMARY OF THE INVENTION

The present invention relates to methods and apparatus for combining assets for a streaming video signal.

In an example embodiment of a method for combining assets for a streaming video signal in accordance with the present invention, video assets are provided in an adaptive bit rate format. The video assets comprise fragments of various types of video content. A stitched manifest identifying a combination of the video assets is created in response to a client request for one or more of the video assets. The stitched manifest is provided to a client and used by the client to request the combination of video assets for playback as one continuous video stream in an order specified by the stitched manifest.

In a further example embodiment of a method for combining assets for a streaming video signal in accordance with the present invention, video programs and additional video content files are provided in an adaptive bit rate format. Therefore, for each of a plurality of video programs, several versions of each of the video programs are provided, and each version is comprised of sets of fragmented files pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, each set of the fragmented files being identified in a corresponding manifest file. Similarly, for each of a plurality of additional video content files, several versions of each of the additional video content files are provided, and each version is comprised of sets of fragmented files pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, each set of the fragmented files of the additional video content files being identified in a corresponding additional manifest file. The manifest files and the additional manifest files identify a source location of the corresponding sets of video fragments and additional video fragments. An asset list is provided identifying the video programs and the additional video content files as video assets. A stitcher is provided for ingesting the asset list, the manifest files, and the additional manifest files and responding with a stitched manifest. The stitched manifest comprises a playlist combining one or more of the video fragments or the additional video fragments of one or more of the video assets. The stitched manifest is then provided to a client, where it is used to request the one or more fragments of the video assets for playback as one continuous video stream in an order specified by the stitched manifest.

The video assets may be, for example, JIT packaging assets or other stored assets. The stitcher may be included as part of a JIT packager or provided as a separate component. Thus, the one or more video assets may be provided to the client using just-in-time packaging. The JIT packager may provide the manifest files and the additional manifest files to the stitcher. The asset list is provided to the stitcher from local storage or in the client manifest request. In addition, the JIT packager may provide the one or more video assets in response to the client request.

The additional video content files may comprise at least one of advertisements, movie previews, public service announcements, movie ratings information, additional video programs, movie or video pre-rolls, programs from different video assets that are desired to be played in sequence, or the like.

Uniform resource locators (URLs) may be used to identify the video fragments and the additional video fragments in the stitched manifest.

In one example embodiment of the present invention, a new URL may be created for each video fragment and each additional video fragment. One of a database or a fixed mapping may be created or provided associating the new URL with an original URL for each video fragment and additional video fragment. The new URLs for the video fragments and additional video fragments may be combined on the stitched manifest. In such an example embodiment, when a request is received from a client for one of the new URLs at the stitcher, the original URL associated with the new URL is identified at the stitcher, and the video fragment or additional video fragment corresponding to the identified new URL is requested from a source (e.g., a video server, content server, or JIT packager) via the stitcher.

The video programs and additional video content files may be delivered using HTTP Live Streaming protocol. The stitched manifest may combine the new URLs of the video fragments and the additional video fragments in sequence for sequential playback at the client.

The video fragments and additional video fragments may be delivered using one of Microsoft® Smooth Streaming (MSS), Adobe® HTTP Dynamic Streaming (HDS), or Dynamic Adaptive Streaming over HTTP (DASH) protocols.

Where the URLs are timestamp-based, each of the video fragments or the additional video fragments have a corresponding timestamp. In such an example embodiment, the stitcher may provide modified timestamps to each new URL. The timestamps of the new URLs may be modified to account for a duration of a previous video fragment or additional video fragment.

Where the URLs are sequence number-based, each of the video fragments or the additional video fragments having a corresponding sequence number. In such an example embodiment, the stitcher may provide modified sequence numbers to each new URL. The sequence numbers of the new URLs may be modified to increase with each of the fragments of the one or more video assets identified on the stitched manifest in sequential order of playback. The stitcher maps the modified sequence numbers to the original sequence numbers to enable retrieval of the requested content.

In a further example embodiment, the additional video content files may comprise advertisements. In such an example embodiment, a placeholder may be provided in the asset list in place of information identifying the additional video content. Upon receipt of a request for a stitched manifest from the client, a specific advertisement may be selected for communication to the client that is related to the client or the one or more video assets subject to the request. The stitched manifest is then created by substituting identification information for the specific advertisement into the asset list in place of the placeholder. The stitched manifest is then provided to the client in response to the request for the stitched manifest. The stitched manifest is then used by the client to play back the requested video asset and the specific advertisement.

A plurality of stitchers may be provided in a video-on-demand system. Playlist servers may be provided to serve the stitched manifest to clients. Load information may be passed from the stitchers to the playlist servers. Load balancing of high-bandwidth-using stitchers may be achieved by enabling the low-bandwidth-using and externally load-balanced playlist servers to select a lightly loaded stitcher from the plurality of stitchers for delivery of the one or more video assets.

In another example embodiment of the present invention, two versions of each video asset may be provided to the stitcher, where the fragments of each version may have a different watermark embedded therein. A unique sequence may then be created comprised of watermarked fragments from the two versions of the watermarked video assets at the stitcher in order to send a different unique sequence to each client. The client's IP address or other identifying information may be encoded in the unique sequence.

The present invention may also include corresponding apparatus for carrying out the methods discussed above. In one example embodiment, a stitcher is provided for combining assets for a streaming video signal in a video distribution environment. In such a distribution environment, one or more video servers store, for each of a plurality of video programs, several versions of each of the video programs comprised of sets of fragmented files pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, each set of the fragmented files being identified in a corresponding manifest file stored together therewith. In addition, one or more content servers store, for each of a plurality of additional video content files, several versions of each of the additional video content files comprised of sets of fragmented files pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, each set of the fragmented files of the additional video content files being identified in a corresponding additional manifest file stored together therewith. The manifest files and the additional manifest files identify a source location of the corresponding sets of video fragments and additional video fragments. An asset list identifies the video programs and the additional video content files as video assets. The stitcher comprises a manifest combiner for ingesting the asset list, the manifest files, and the additional manifest files and responding with a stitched manifest, the stitched manifest comprising a playlist combining one or more of the video fragments or the additional video fragments of one or more of the video assets. The manifest combiner provides the stitched manifest to a client, the stitched manifest being used at the client to request the one or more fragments of the video assets for playback. The stitcher may also comprise a fragment proxy for obtaining the one or more fragments of the video assets from the one or more video servers or the one or more content servers and delivering the one or more fragments of the video assets to the client as one continuous video stream in an order specified by the stitched manifest.

The stitcher also comprises various features and elements for carrying out the various methods discussed above, including but not limited to a database for URL mapping and/or a mapping algorithm for mapping original URLs to newly created URLs.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will hereinafter be described in conjunction with the appended drawing figures, wherein like reference numerals denote like elements, and:

FIG. 1 is a block diagram showing an example embodiment of the present invention, illustrating the return of a stitched manifest and the provision of video content to a client;

FIG. 2 is a block diagram showing an example embodiment of a stitcher in accordance with the present invention;

FIG. 3 is a block diagram showing a further example embodiment of the present invention;

FIG. 4 is a block diagram showing a further example embodiment of the present invention, illustrating the return of a stitched manifest and the insertion of targeted advertisement content to a client, as well as load balancing; and

FIG. 5 is a block diagram showing a further example embodiment of the present invention, illustrating the packaging of watermarked assets and delivery of these assets to clients.

DETAILED DESCRIPTION

The ensuing detailed description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the invention. Rather, the ensuing detailed description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an embodiment of the invention. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims.

FIG. 1 shows a block diagram of an example embodiment of the present invention for combining assets for a streaming video signal. Video programs and additional video content files are provided in an adaptive bit rate format by corresponding servers (video servers10 or content servers12) or just-in-time packagers14. Therefore, for each of a plurality of video programs, several versions of each of the video programs are provided, and each version is comprised of sets offragmented files16 pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, each set of thefragmented files16 being identified in acorresponding manifest file18. Similarly, for each of a plurality of additional video content files, several versions of each of the additional video content files are provided, and each version is comprised of sets offragmented files16 pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, each set of thefragmented files16 of the additional video content files being identified in a correspondingadditional manifest file18. The manifest files and the additional manifest files18 identify a source location of the corresponding sets ofvideo fragments16 and additional video fragments16. Anasset list20 is provided identifying the video programs and the additional video content files as video assets. Astitcher22 is provided for ingesting theasset list20, the manifest files18, and the additional manifest files18 and responding with a stitchedmanifest24. The stitchedmanifest24 comprises a playlist combining one or more of the video fragments16 or theadditional video fragments16 of one or more of the video assets. The stitchedmanifest24 is then provided to aclient26, where it is used to request the one ormore fragments16 of the video assets for playback as one continuous video stream in an order specified by the stitchedmanifest24.

AlthoughFIG. 1 shows thestitcher22 as a separate component, it should be appreciated that the stitcher may be included as part of aJIT packager14. Thus, the video assets may be provided to theclient26 using just-in-time packaging. TheJIT packager14 may provide the manifest files18 and the additional manifest files18 to the stitcher. Theasset list20 may be provided to thestitcher22 either from local storage or in theclient26 request for the stitchedmanifest24. In addition, theJIT packager14 may provide thefragments16 of the one or more video assets in response to the client request.

Theasset list20 may be stored at the playlist server, at an external content management system (CMS)54 (as discussed below in connection withFIG. 4), or at any external storage component.

Further, it should be appreciated that the JIT packager(s)14 may function as anothervideo server10 orcontent server12, and therefore it should be appreciated that wherever avideo server10 orcontent server12 is mentioned herein, aJIT packager14 may be substituted therefore.

The additional (or original) video content files (from content server(s)12) may comprise at least one of advertisements, movie previews, public service announcements, movie ratings information, additional video programs, movie or video pre-rolls, programs from different video assets that are desired to be played in sequence, or the like.

Manifests in HTTP streaming use one of two methods to specify the uniform resource locators (URLs) of the fragments. HTTP Live Streaming (HLS), which allows streaming of live and on-demand video and audio to an Apple® iPhone®, iPad®, or iPod® Touch, uses complete URLs in its manifests. The client requests the URLs in the manifests and plays the fragments sequentially. Microsoft® Smooth Streaming (MSS) and Adobe® HTTP Dynamic Streaming (HDS) use a template URL in which a time stamp or sequence number is used to refer to specific fragments.

Similarly, URLs may be used to identify the video fragments16 and theadditional video fragments16 in the stitchedmanifest24. In the stitchedmanifest24, the timestamps or sequence numbers of the URLs can be updated to calculate the timestamp or sequence number of the next fragment from the previous fragment. For MSS, for example, the duration of a fragment is added to its timestamp in order to compute the timestamp of the next fragment. Dynamic Adaptive Streaming over HTTP (DASH) uses a mixture of both techniques.

FIG. 2 shows a block diagram of an example embodiment of astitcher22 in accordance with the present invention. Thestitcher22 may comprise amanifest combiner30 for ingesting theasset list20, the manifest files18, and the additional manifest files18, and responding to theclient26 with a stitchedmanifest24. Themanifest combiner30 provides the stitchedmanifest24 to theclient26 in response to aclient request38. Thestitcher22 also comprises afragment proxy32 receiving arequest40 for acontent fragment16 from the client26 (as identified in the stitched manifest24) and requesting42 and receiving44 the one ormore fragments16 of the video assets from the one ormore video servers10 or the one or more content servers12 (or one or more JIT packagers14). Thefragment proxy32 then delivers the one ormore fragments16 of the video assets to theclient26 for eachsequential request40 to form one continuous video stream at theclient26 in an order specified by the stitchedmanifest24.

In an alternate embodiment as shown inFIG. 3, fragments16 with original URLs can be served directly to the client from the correspondingvideo server10,content server12, orJIT packager14. In such an example embodiment, the manifest files18 are provided to thestitcher22 for use in creating the stitchedmanifest24, and thestitcher22 receives the request for content from theclient26 and communicates this request to theservers10,12,14, which provide the requested fragments16 to the client directly. For example, such an embodiment is suitable for the case of HLS-type URL playlists, so that the URLs can be combined and played in sequence.

In a further example embodiment of the present invention, a new URL may be created for eachvideo fragment16 and eachadditional video fragment16. Adatabase34 and/or a fixed mapping algorithm36 (as shown inFIG. 2) may provided at thestitcher22 associating the new URL with an original URL for eachvideo fragment16 andadditional video fragment16. The new URLs for the video fragments16 and additional video fragments16 may be combined on the stitchedmanifest24. In such an example embodiment, when a request is received from aclient26 for one of the new URLs at thestitcher22, the original URL associated with the new URL is identified at thestitcher22 using thedatabase34 and/or themapping algorithm36, and thevideo fragment16 oradditional video fragment16 corresponding to the identified new URL is requested from a source (e.g., a correspondingvideo server10,content server12, or JIT packager14) via thestitcher22.

This allows all URLs in the stitchedmanifest24 to have the same format and to refer to the same server and path namespace. This has the advantage that it is not readily possible to differentiate (and thus excise) advertisement URLs from the network program URLs in order to allow advertisements to be skipped.

The video fragments16 and additional video fragments16 may be delivered using one of Microsoft® Smooth Streaming (MSS), Adobe® HTTP Dynamic Streaming (HDS), or Dynamic Adaptive Streaming over HTTP (DASH) protocols. The video programs and the additional video content files may also be delivered using HTTP Live Streaming protocol. The stitchedmanifest24 may combine the URLs of the video fragments16 and theadditional video fragments16 in sequence for sequential playback at theclient26.

Normally, the URLs for different assets using HDS- or MSS-type URLs have different name spaces. That is, the path portion of the URL is different. This makes playing different assets contiguously impossible, since theclient26 will not know when to stop updating timestamps or sequence numbers and to change namespaces. However, thestitcher22 can map the path portion (or any other portion of the URL) using itsinternal database34, so that a single namespace in the stitchedmanifest24 is converted into internal requests from multiple namespaces. Thestitcher22 effectively serves as a proxy that returns withsequential fragments16 from multiple assets based on a manifest24 with just one name space.

Where the URLs are timestamp-based, each of the video fragments16 or theadditional video fragments16 have a corresponding timestamp. In the case of timestamp-based URLs, theclient26 will use a fragment's duration to compute the next timestamp. Thus, the stitchedplaylist24 must use consistent timestamps that account for the duration of eachfragment16. In such an example embodiment, thestitcher22 may provide modified timestamps to each new URL. The timestamps of the new URLs may be modified to account for a duration of aprevious video fragment16 oradditional video fragment16.

In particular, if the asset A₁in theasset list20 has time stamps, T_1,1, . . . , T_1,N1, with asset A2 having time stamps T_2,1, . . . , T_2,N2, etc, then the stitchedplaylist24 will have timestamps:

$<figure-callout\; label="\; T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}"><figure-callout\; label="\; T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}"></figure-callout></figure-callout>\underset{}{T_{}}\underset{}{{}_{}}\underset{\left[--\mathrm{first}\mathrm{asset}-\right]}{{}_{1,1},\dots ,{\mathrm{<figure-callout\; label="T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}">T</figure-callout>}}_{1,N1},}$$\underset{\left[---------\mathrm{second}\mathrm{asset}-------------------\right]}{\left(\left({\mathrm{<figure-callout\; label="T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}">T</figure-callout>}}_{2,2}-{\mathrm{<figure-callout\; label="T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}">T</figure-callout>}}_{2,1}\right)+{\mathrm{<figure-callout\; label="T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}">T</figure-callout>}}_{1,N1}\right),\left(\left({\mathrm{<figure-callout\; label="T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}">T</figure-callout>}}_{2,3}-{\mathrm{<figure-callout\; label="T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}">T</figure-callout>}}_{2,1}\right)+{\mathrm{<figure-callout\; label="T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}">T</figure-callout>}}_{1,N1}\right),\dots ,\left({\mathrm{<figure-callout\; label="T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}">T</figure-callout>}}_{2,N2}-{\mathrm{<figure-callout\; label="T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}">T</figure-callout>}}_{2,1}\right)+{\mathrm{<figure-callout\; label="T"\; filenames="US08887215-20141111-D00000.png,US08887215-20141111-D00001.png"\; state="\{\{state\}\}">T</figure-callout>}}_{1,N1})},\dots ,\dots$
The first term of the timestamps for the second asset ensures that adding the duration of the first fragment of asset A₂to the last time stamp of the last fragment of asset A₁will create the timestamp for the first asset of A₂, etc.

Where the URLs are sequence number-based URLs, each of the video fragments16 or theadditional video fragments16 having a corresponding sequence number. In such an example embodiment, thestitcher22 may provide modified sequence numbers to each new URL. The sequence numbers of the new URLs may be modified to increase with each of thefragments16 of the one or more video assets identified on the stitchedmanifest24 in sequential order of playback. Thestitcher22 maps (e.g., via the mapping algorithm36) the modified sequence numbers to the original sequence numbers to enable retrieval of the requested content.

Thestitcher22 may also combine sub-portions of programs by selecting a portion of the manifest18 for an asset for inclusion in the stitchedmanifest24. The sub-portion can be defined by start and stop timestamps or sequence numbers, or by selecting a subset of the URLs in an HLS-style manifest.

In a further example embodiment, the additional video content files provided by thecontent servers12 may comprise advertisements (in particular, targeted advertisements).FIG. 4 shows a block diagram of such an example embodiment of the invention. A placeholder may be provided in theasset list20 in place of information identifying the additional video content. Upon receipt of a request for a stitchedmanifest24 from theclient26, a specific advertisement may be selected for communication to theclient26 that is related to the client or the one or more video assets subject to the request. The stitchedmanifest24 is then created by substituting identification information for the specific advertisement into theasset list20 in place of the placeholder. The stitchedmanifest24 is then provided to theclient26 in response to the request for the stitched manifest. The stitchedmanifest24 is then used by theclient26 to play back the requested video asset and the specific advertisement.

In particular, as shown inFIG. 4, a placement opportunity information server/ad decision server (POIS/ADS)50 is used to serve ad decisions toplaylist servers52. Theplaylist servers52 may be used to serve the stitched manifests24 to theclient26 in response to the client request, and to convert the placeholders in the stitchedmanifest24 into specific advertisement identification information obtained from the POIS/ADS50. When aclient26 makes a request for a stitchedmanifest24, theplaylist server52 connects to theADS50, requests specific ads for theclient26 and the content that is to be viewed, converts the advertisement placeholders into requests for specific assets, fetches the stitchedmanifest24 and returns it to theclient26. Theclient26 then plays back the content by making requests directly to thestitcher22 based on the URLs in the stitchedmanifest24. A content management system (CMS)54 may be used to store the asset lists20 and templates for the asset lists20 (an asset list template may be an asset list with a placeholder for an advertisement).

Amanagement system56 may be provided to manage and integrate the components of the system. Anencryption key server58 may be used with theJIT packager14 to encrypt thefragments16. Content may be provided directly by the JIT packager(s)14 or fromvideo servers10 andcontent servers12 through theJIT packagers14. Communication with the client(s)26 may take place over a content delivery network (CDN)60.

In accordance with a further example embodiment of the present invention, efficient load balancing is provided. Normally, video servers that service large numbers of clients (as may be expected to be the case at video service providers that offer VOD service) must be load balanced to deal with the large number of HTTP requests made by large numbers of clients connecting simultaneously. Using the architecture described herein has the advantage that only the low bandwidth-usingplaylist servers52 need to be load balanced. Theplaylist servers52 can then load balance thestitchers22 and/orJIT Packagers14 as is shown inFIG. 4. It should be noted that the bulk of utilized bandwidth is in the delivery of the fragments, and the onus of load balancing this traffic is eliminated.

In such a load balancing example embodiment, a plurality ofstitchers22 may be provided in a video-on-demand system.Multiple playlist servers52 may be provided to serve the stitchedmanifest24 toclients26. Load information may be passed from thestitchers22 to theplaylist servers52. Load balancing of high-bandwidth-usingstitchers22 may be achieved by enabling the low-bandwidth-using and externally load-balanced playlist servers52 to select a lightly loadedstitcher22 from the plurality ofstitchers22 for delivery of the one or more video assets.

Another example embodiment of the present invention enables unique watermarking technique. In such an example embodiment, two versions of each video asset may be provided to thestitcher22, where thefragments16 of each version may have a different watermark embedded therein. A unique sequence may then be created comprised of watermarked fragments from the two versions of the watermarked video assets at thestitcher22 in order to send a different unique sequence to eachclient26. The client's IP address or other identifying information may be encoded in the unique sequence.

FIG. 5 shows a block diagram of an example embodiment of such a watermarking embodiment. Thecontent70 is subject to anexternal watermarking process72 and different watermarked versions of the content70 (or fragments of the content70) are stored at one or more video servers orcontent servers74. As with the embodiments discussed above, the fragments of the watermarkedcontent70 are identified in amanifest file18 provided to thestitcher22, which creates the unique sequence of watermarked fragments in response to the client request for content.

There are multiple techniques for adding so-called ‘watermarks’ to video, audio, and transport data. These watermarks are designed to not interfere with the data in which they are embedded, but to be extractable later. The specific method of watermarking is not important to the present invention; any of a myriad of different techniques can be used.

Content owners use watermarks as a deterrent to piracy, since pirated content can be traced back to the user that distributed it by extracting the user-specific watermark in the content. However, creating a watermark for each user can be computationally demanding. The present invention provides a method for using only two different watermarks and thestitcher22 to create individually targeted watermarks for effectively arbitrarily many different users.

More particularly, an asset may be watermarked twice using two different watermarks. The fragments from each version of the watermarkedcontent70 are aligned so that they start and stop at the same frames. Thestitcher22 may be used to selectfragments16 from each version in such a way as to create a unique sequence of alternate versions that can be used to identify the receivingclient26. The alternating fragments can be used to encode the client's IP address or other identifying information. It should be noted that a specific advantage of this technique is that the “0” and “1” chunks can be cached in a CDN, which is not normally the case with watermarks that target specific users.

It should now be appreciated that the present invention provides advantageous methods and apparatus for combining different assets for continuous playback in a streaming video signal.

Although the invention has been described in connection with various illustrated embodiments, numerous modifications and adaptations may be made thereto without departing from the spirit and scope of the invention as set forth in the claims.

Claims (19)

What is claimed is:

1. A method for combining assets for a streaming video signal in a video-on-demand environment, comprising:

providing, for each of a plurality of video programs, several versions of each of the video programs comprised of sets of fragmented files pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, each set of the fragmented files being identified in a corresponding manifest file;

providing, for each of a plurality of additional video content files, several versions of each of the additional video content files comprised of sets of fragmented files pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, each set of the fragmented files of the additional video content files being identified in a corresponding additional manifest file;

the manifest files and the additional manifest files identifying a source location of the corresponding sets of video fragments and additional video fragments;

providing an asset list identifying the video programs and the additional video content files as video assets;

providing a stitcher for ingesting the asset list, the manifest files, and the additional manifest files and responding with a stitched manifest, the stitched manifest comprising identifiers for one or more of the video fragments or the additional video fragments of one or more of the video assets;

providing the stitched manifest to a client in response to a client request for the stitched manifest; and

using said stitched manifest at the client to request the one or more fragments of the video assets in sequence for sequential playback as one continuous video stream in an order specified by the stitched manifest;

the identifiers comprising uniform resource locators (URLs) which are used to identify the video fragments and the additional video fragments in the stitched manifest;

creating a new URL for each video fragment and each additional video fragment;

creating one of a database or a fixed mapping associating the new URL with an original URL for each video fragment and additional video fragment;

combining the new URLs for the video fragments and additional video fragments on the stitched manifest;

receiving the client request at the stitcher;

identifying the original URL associated with the new URL at the stitcher; and

requesting the video fragment or additional video fragment corresponding to the identified new URL from the source location via the stitcher.

2. A method in accordance withclaim 1, wherein:

the one or more video assets are provided to the client using just-in-time packaging;

a just-in-time packager provides the manifest files, the additional manifest files, and the asset list to the stitcher; and

the just-in-time packager provides the one or more video assets in response to the client request for the one or more fragments of the video assets.

3. A method in accordance withclaim 1, wherein the additional video content files comprise at least one of advertisements, movie previews, public service announcements, movie ratings information, additional video programs, movie or video pre-rolls, or programs from different video assets that are desired to be played in sequence.

4. A method in accordance withclaim 1, wherein:

the video programs and the additional video content files are delivered using HTTP Live Streaming protocol; and

the stitched manifest combines the URLs of the video fragments and the additional video fragments in sequence for sequential playback at the client.

5. A method in accordance withclaim 1, wherein:

the video programs and additional video content files are delivered using HTTP Live Streaming protocol; and

the stitched manifest combines the new URLs of the video fragments and the additional video fragments in sequence for sequential playback at the client.

6. A method in accordance withclaim 1, wherein:

the video fragments and additional video fragments are delivered using one of Microsoft® Smooth Streaming (MSS), Adobe® HTTP Dynamic Streaming (HDS), or Dynamic Adaptive Streaming over HTTP (DASH) protocols.

7. A method in accordance withclaim 6, wherein:

the URLs are timestamp-based, each of the video fragments or the additional video fragments having a corresponding timestamp;

the stitcher provides modified timestamps to each new URL; and

the timestamps of the new URLs are modified to account for a duration of a previous video fragment or additional video fragment.

8. A method in accordance withclaim 6, wherein:

the URLs are sequence number-based URLs, each of the video fragments or the additional video fragments having a corresponding sequence number;

the stitcher provides modified sequence numbers to each new URL;

the sequence numbers of the new URLs are modified to increase with each of the fragments of the one or more video assets identified on the stitched manifest in sequential order of playback; and

the stitcher maps the modified sequence numbers to the original sequence numbers to enable retrieval of the requested content.

9. A method in accordance withclaim 1, wherein the additional video content files comprise advertisements, further comprising:

providing a placeholder in the asset list in place of information identifying the additional video content;

upon receipt of the request for the stitched manifest from the client, selecting a specific advertisement for communication to the client that is related to the client or the one or more video assets subject to the request;

creating the stitched manifest by substituting identification information for the specific advertisement into the asset list in place of the placeholder;

providing the stitched manifest to the client in response to the request for the stitched manifest; and

using the stitched manifest by the client to play back the requested video asset and the specific advertisement.

10. A method in accordance withclaim 1, further comprising:

providing a plurality of stitchers in a video-on-demand system;

providing playlist servers to serve the stitched manifest to clients;

passing load information from the stitchers to the playlist servers; and

load balancing high-bandwidth-using stitchers by enabling the low-bandwidth-using and externally load-balanced playlist servers to select a lightly loaded stitcher from the plurality of stitchers for delivery of the one or more video assets.

11. A method in accordance withclaim 1, further comprising:

providing two versions of each video asset to the stitcher, the fragments of each version having a different watermark embedded therein; and

creating a unique sequence comprised of watermarked fragments from the two versions of the watermarked video assets at the stitcher in order to send a different unique sequence to each client.

12. A method in accordance withclaim 11, further comprising:

encoding the client's IP address or other identifying information in the unique sequence.

13. A method for combining video assets for a streaming video signal in a video-on-demand environment, comprising:

providing, for each of a plurality of video assets, several versions of each of the video assets pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, said video assets comprising fragments of various types of video content;

creating a stitched manifest comprising identifiers for a combination of different video assets from the plurality of video assets in response to a client request for the different video assets;

providing the stitched manifest to a client in response to the client request; and

using said stitched manifest at the client to request the combination of the different video assets in sequence for sequential playback as one continuous video stream in an order specified by the stitched manifest;

the identifiers comprising uniform resource locators (URLs) which are used to identify the video assets in the stitched manifest;

creating a new URL for each video asset;

creating one of a database or a fixed mapping associating the new URL with an original URL for each video asset;

combining the new URLs for the video assets on the stitched manifest;

identifying the original URLs associated with the new URLs; and

and requesting the video assets corresponding to the identified new URLs from a source location.

14. An apparatus for combining assets for a streaming video signal in a video distribution environment, wherein:

one or more video servers store, for each of a plurality of video programs, several versions of each of the video programs comprised of sets of fragmented files pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, each set of the fragmented files being identified in a corresponding manifest file stored together therewith;

one or more content servers store, for each of a plurality of additional video content files, several versions of each of the additional video content files comprised of sets of fragmented files pre-encoded at correspondingly different bit rates, codecs or resolutions in an adaptive bit rate format, each set of the fragmented files of the additional video content files being identified in a corresponding additional manifest file stored together therewith;

the manifest files and the additional manifest files identify a source location of the corresponding sets of video fragments and additional video fragments;

an asset list identifies the video programs and the additional video content files as video assets;

the comprises apparatus comprising:

a manifest combiner for ingesting the asset list, the manifest files, and the additional manifest files and responding with a stitched manifest, the stitched manifest comprising identifiers for one or more of the video fragments or the additional video fragments of one or more of the video assets;

the manifest combiner providing the stitched manifest to a client in response to a client request for the stitched manifest, the stitched manifest being used at the client to request the one or more fragments of the video assets for playback; and

a fragment proxy for obtaining the one or more fragments of the video assets from the one or more video servers or the one or more content servers and delivering the one or more fragments of the video assets in sequence to the client for sequential playback as one continuous video stream in an order specified by the stitched manifest; wherein: the identifiers comprise uniform resource locators (URLs) which are used to identify the video fragments and the additional video fragments in the stitched manifest;

a new URL is created for each video fragment and each additional video fragment;

the apparatus further comprises one of an additional database or a fixed mapping associating the new URL with an original URL for each video fragment and additional video fragment;

the manifest combiner combines the new URLs for the video fragments and additional video fragments on the stitched manifest;

a client request is received at the fragment proxy;

the fragment proxy identifies the original URL associated with the new URL via communications with the additional database or the fixed mapping;

and the fragment proxy requests the video fragment or additional video fragment corresponding to the identified new URL from the one or more video servers or from the one or more content servers.

15. An apparatus in accordance withclaim 14, wherein:

the URLs are timestamp-based, each of the video fragments or the additional video fragments having a corresponding timestamp;

modified timestamps are provided to each new URL; and

the timestamps of the new URLs are modified to account for a duration of a previous video fragment or additional video fragment.

16. An apparatus in accordance withclaim 14, wherein:

the URLs are sequence number-based URLs, each of the video fragments or the additional video fragments having a corresponding sequence number;

modified sequence numbers are provided to each new URL;

the sequence numbers of the new URLs are modified to increase with each of the fragments of the one or more video assets identified on the stitched manifest in sequential order of playback; and

the additional database or the fixed mapping maps the modified sequence numbers to the original sequence numbers to enable retrieval of the requested content.

17. An apparatus in accordance withclaim 14, wherein:

a plurality of the apparatus for combining assets for a streaming video signal are provided in a video-on-demand system;

playlist servers are provided to serve the stitched manifest to clients;

load information is passed from each of the apparatus to the playlist servers; and

high-bandwidth-using apparatus are load balanced by enabling the low-bandwidth-using and externally load-balanced playlist servers to select a lightly loaded apparatus from the plurality of apparatus for delivery of the one or more video assets.

18. An apparatus in accordance withclaim 14, wherein:

two versions of each video asset are provided to the apparatus, the fragments of each version having a different watermark embedded therein; and

a unique sequence is created at the apparatus comprised of watermarked fragments from the two versions of the watermarked video assets in order to send a different unique sequence to each client.

19. An apparatus in accordance withclaim 14, wherein:

the additional video content files comprise advertisements;

a placeholder is provided in the asset list in place of information identifying the additional video content;

upon receipt of the request for a stitched manifest from the client, a specific advertisement is selected for communication to the client that is related to the client or the one or more video assets subject to the request;

the stitched manifest is created by substituting identification information for the specific advertisement into the asset list in place of the placeholder;

the stitched manifest is provided to the client in response to the request for the stitched manifest; and

the stitched manifest is used by the client to play back the requested video asset and the specific advertisement.

Images