Patent ID: 12206918

DETAILED DESCRIPTION

The following detailed description of the invention is merely exemplary in nature and is not intended to limit the invention or the application and uses of the invention. Furthermore, there is no intention to be bound by any theory presented in the preceding background or the following detailed description.

According to various embodiments, a data processing system is provided to process raw media content (e.g., television programs, movies, and other content) for a video on demand (VOD) type services. Typically, content is encoded and packaged on demand for a particular type of client (e.g., a particular brand of phone or other media player device, or a particular media player client). The encoded content is packaged with appropriate digital rights management (DRM) for that media client and delivered to the media player for playback. The packaged content can also be stored in a cache (e.g., a CDN127associated with the Internet or other network125) so that subsequent requests for the same content that are received from other media players of the same type as the originally-requesting player can be processed from the cache, without the need to re-package or re-secure with additional DRM. While this may consume additional processing resources to package the initial request, many embodiments will consume substantially less cache storage (since only versions that are actually used need to be cached). Moreover, the need to live encode future DRM can be reduced if the DRM can be re-used by other secure clients, as described herein.

Many modern media delivery systems use different types of encoding and DRM to deliver content to different types of clients. Apple devices, for example, typically use FairPlay DRM, whereas Microsoft products (e.g., Xbox media players and Windows Media Player) use PlayReady DRM, and Android players typically use Widevine DRM. A content delivery service that supports multiple media player clients, then, must typically support multiple types of DRM. Moreover, adaptive media delivery typically involves the encoding of multiple copies of each program to ensure proper quality levels are available for delivery. While the fastest delivery technique would typically involve encoding each program at each quality level with each DRM type, this would result in a substantial demand for processing resources, as well as substantial data storage requirements. Data storage could be particularly expensive if the pre-encoded content is stored in a commercial CDN, which typically charges based upon the amount of data that is cached.

It is far more efficient, then, to fractionalize the content based upon the operating system (e.g., iOS, Android, Windows, etc.) or device type (e.g., iPhone, Android phone, Apple brand tablet, Microsoft brand tablet, Android tablet, etc.) rather than the program itself, since different devices use different DRM techniques and services. Different devices may also have different profiles: a mobile phone may require lower quality than a home-type media player (e.g., a Roku, Apple TV, ChromeCast or similar device), for example, due to the smaller screen. Encoding quality may be considered in addition to DRM type to create a manageable number of encoding profiles for different devices. Each profile can then be packaged, protected with a cryptographic key, and stored in the cache for convenient delivery. The cryptographic key can be securely delivered for the different media packages using any number of different DRM types. This ensures relatively quick delivery for at least the most common devices without requiring packaging and storage of data that is unlikely to be requested.

Turning now to the drawing figures and with initial reference toFIG.1, an example video processing and delivery system100is shown. The system100illustrated inFIG.1includes a video server system that encodes and delivers video programs to one or more remotely-located video player clients130via the Internet or another network125. Some programs may be encoded in advance of delivery and stored in storage110and/or content delivery network (CDN)127for immediate retrieval. Other programs, however, are encoded and/or packaged on an as-needed basis using a packaging system106that retrieves the content from the origin server112, packages a video stream with appropriate digital rights management (DRM) for the device requesting the content, and supplies the encoded video package to a content delivery network (CDN)127for delivery to the media player client device130. The package that is formed for a particular client may be maintained in cache storage with the CDN127for an appropriate period of time; when subsequent requests are received for the same content to be delivered to the same type of device (or otherwise having the same parameters are the earlier package), then the previously-packaged stream can be delivered by the CDN127without additional encoding, DRM and other processing. Because the video content is packaged as-needed for a particular client130, the storage/caching may be limited to only the formats and quality levels that are actually used, thereby greatly reducing the amount of storage space that would be required for appropriate delivery. That is, it is no longer necessary to encode, DRM protect and store packages that may not be used, thereby freeing up storage and reducing costs. Additional details are set forth below.

Video server system100suitably includes an intake store102, a bulk video encoding system103, an origin server112, a publishing system105and a packaging system106as appropriate. Each of the components of server system101is typically implemented using conventional computing hardware and software, including any sort of cloud-based data processing capabilities, as desired. Each of the components therefore typically includes a conventional processor that is capable of executing software or firmware programs that are stored in memory or mass storage to execute the various functions and processes described herein.

Origin server112is a computerized server that delivers media content119to one or more remotely-located media player devices130via network125. In various embodiments, origin server112is implemented using one or more conventional network server systems that incorporate any number of processors, memory, input/output interfaces and/or the like. Typically, origin server112executes a software or firmware program that implements the various functions described herein. Equivalent embodiments could use cloud-based computing resources to implement origin server112, as desired. Still other embodiments may implement origin server112using any number of inter-operating computing systems, such as any sub-systems that provide user authentication/authorization, digital rights management (DRM), cryptography, billing, interface handling, redundant processing, load balancing and/or other functions as appropriate.

Encoding systems103retrieve raw program content from intake store102and compress or otherwise format the program data for delivery on network125. Intake store102is a database or other repository for received media programs prior to processing for delivery. In various embodiments, intake store102is a database system (including conventional processing, memory and input/output capabilities) that receives and stores master files prior to encoding or further processing. Such master files may be lightly compressed (or even uncompressed) mezzanine files, MPEG transport streams (TS) received via a satellite, cable or terrestrial broadcast, and/or another type of source content received from a content owner, distributor, broadcast and/or other source. In some embodiments, intake store102may perform some initial processing on the received content (e.g., tagging or otherwise identifying the received content), although primary compression and other encoding will typically occur at later stages.

As noted above, at least some programs may be encoded a priori for storage on a CDN127or the like. Typically, encoding of such programs will be handled by a bulk encoder system103that provides encoding into one or more appropriate formats and qualities. U.S. Pat. No. 8,621,099 assigned to Sling Media Inc. of Foster City, California describes one example of a cloud-based bulk media intake/encoding system, although other embodiments could use any other systems and processes as desired.

One or more encoders103suitably convert content from the master file format maintained in content store102to one or more compressed formats for distribution on network125. In various embodiments, content may be converted from MPEG or other source formats into any number of different formats to ensure compatibility with different types of devices and media players130. Alternatively, content received in any number of different formats may be encoded into a common MPEG transport stream or similar format, as desired. For adaptive streaming, encoder103may encode two or more different bit rates, frame rates, resolutions or other qualities as appropriate so that the media stream may be adapted during transmission to the player130. U.S. Pat. No. 8,612,624 assigned to Echostar Technologies of Englewood, Colorado describes several types of adaptive streaming techniques, although equivalent embodiments could use any other types and formats for adaptive encoding and streaming as desired. Many VOD services maintain a substantial number of different copies of each video due to the wide range of formats and video qualities that are supported.

Various embodiments could additionally or alternately receive content that is already encoded in the desired directly from the producer of the content (e.g., a television network) or another third party service104, as desired. In such cases, it may not be necessary to further encode the video content, although it may still be desirable to package and publish the content in the same manner as content encoded by encoders103, as described more fully herein.

Various embodiments additionally provide a publishing service105that formats the encoded video content in a suitable manner for distribution/publishing on network125. Publishing service105is typically implemented using a digital computing system having a processor and memory capable of executing software, firmware or other programmed logic to execute the various functions and processes described herein. Publishing service105may be equivalently implemented using cloud-type processing services that abstract the data processing hardware, as desired.

In operation, publishing service105is able to re-organize or realign the encoded content for proper formatting and timing in accordance with the streaming media formats supported by the media player130. This re-organization may involve renaming segment or other data files, for example, so that the file names are compliant with a URL or other addressing scheme used by the media player130or by CDN127. Publishing service105may also create appropriate metadata to describe data segments, data files or the like that can be retrieved by the media player. This metadata may ultimately be delivered in a digest to the media player130to allow the player to request appropriate content files in an adaptive streaming session, for example.

The publishing server105therefore places encoded content and/or content received directly from third parties104into a suitable format that can be stored in origin server112and further processed by packaging server106. This format will typically include sets of data segments that can be individually retrieved by media players130using HTTP or similar constructs via network125.

The encoded and formatted media content is typically stored with an origin server112prior to delivery to media players130. Origin server112is typically a conventional file server system that stores individually-accessible data files for retrieval by media player devices130operating on network125. In various embodiments, file server112acts as an origin server for CDN127; that is, files retrieved from the origin server112can be redistributed and cached at various geographically-dispersed servers throughout CDN127so that subsequent requests for the same content that are received from other media players130can be processed more quickly.

To that end, content can be packaged prior to delivery by packaging server106, which creates a bundle that can be stored with origin server112and/or CDN127for delivery to media players130as appropriate. The formatting and distribution of video content will vary from embodiment to embodiment. In many implementations, it will be beneficial to perform a quality assurance analysis on the completed package to ensure that formatting and encoding were performed correctly. Quality assurance will typically identify any encoding or formatting errors prior to distribution, but it can consume additional processing resources. Packaging system106may be implemented using any sort of conventional computing hardware, including any sort of processor, memory and input/output interfaces. Other embodiments may use cloud-based hardware (e.g., the cloud-based server systems available from Amazon Web Services or the like).

As noted above, encoded and packaged content118may be stored in a origin or other file storage112for subsequent delivery to media players130via network125. In many embodiments, origin server112handles requests for content119from media players130. If the requested content is already encoded, then the encoded content can be retrieved from storage for delivery and/or caching with CDN127. Future requests for the same content by the same or other media players130may then be redirected toward CDN127for more effective delivery without consulting origin server112, as desired.

Media player device130is any sort of media player, computer system, mobile phone, tablet, video game player, television, television receiver, set top box, video recorder and/or other device that is capable of receiving streaming media content via network125. Typically, media player device130includes any sort of conventional hardware131such as a processor, memory, input/output interfaces and/or the like to carry out the various functions and processes set forth herein. In various embodiments, media player device130executes a software application132that is stored in memory and executed by the processor to carry out the various functions described herein. Software application132may include an application program interface (API) or software development kit (SDK) that is compatible with system100in general, and/or publishing system105in particular, to allow delivery of live encoded video streams. Application132may include a placeshifting or media player client, for example, that is developed to be compatible with encoding and delivery system100, as described herein.

Typically, viewers operate a user interface of media player130to select and retrieve video content from server112via network125. In many implementations, server112stores at least some of the available video content with one or more content delivery networks (CDNs)127. CDN127typically maintains any number of edge servers that are geographically and/or logically distributed throughout network125so that users in any location can obtain relatively streamlined access to requested video files. In many embodiments, the media player130initially contacts server112directly for authentication, authorization and/or access to lists of available programs. When a desired program is selected, media player130may be redirected to an edge server affiliated with CDN127that is closer to the requesting media player130or that can otherwise provide more efficient delivery than the origin server112. Typically, each edge server in CDN127initially receives encoded content from origin server112. The received content may be cached at least temporarily in case another media player130requests the same content from the same edge server. As noted above, however, CDN services are typically relatively expensive, so caching unpopular programs118with a CDN127may result in unnecessary cost.

When a pre-encoded version of a requested program118is not available within system100, media player130interacts with system100to obtain a suitable media package created for the particular media player130. Generally speaking, the package that is created will be based upon the appropriate video format, DRM type, and/or quality levels for the particular type of device130.

To that end, system100will typically respond to a request from the media player130by obtaining un-encoded content from intake store102, encoding the appropriate formats for media player130, encrypting the content as appropriate, packaging the encoded content with suitable DRM for that player, and delivering the encoded package to the media player device130for playback. The encoded package may also be cached with CDN127or the like for delivery to other media players of the same type as player130that request the same content in the future.

Content may not be live encoded; in some embodiments, the content is encoded a priori into an appropriate number of formats and quality levels for storage associated with origin server112. The appropriately-formatted content may nevertheless be retrieved from storage112and packaged in response to a request from a media player130, as desired, if the particular DRM scheme allows.

Packaging suitably involves obtaining the video and audio content for the requested programming in the appropriate format and/or at appropriate levels for the requesting media player, encrypting the content with a suitable cryptographic key, and assigning appropriate DRM for the package. In various embodiments, content may be encrypted before or after encoding, and/or DRM may be applied prior to delivery as described herein. In an example embodiment, packaging system106includes a cryptographic key store121that generates keys of suitable length according to any appropriate algorithm or process, which is usually defined by the relevant DRM service. Cryptographic keys are typically used to generate symmetric or asymmetric encryption, digital signatures and/or other features as defined by the DRM standard that is applied. Keys may then be shared with the DRM service using secure protocols (and/or other techniques, including secure physical links) for subsequent retrieval by media player(s)130. When media player130retrieves the package of encoded content via network125, it appropriate contacts DRM service120to obtain the needed key; the key maybe re-used, in some embodiments, for other media players130of the same type to prevent re-encoding or re-packaging by system100. The media package that is created, then, can be stored on the CDN127for subsequent delivery to multiple devices130, which each obtain the appropriate key for decryption and viewing through the appropriate DRM service120.

FIG.2shows on example of a process200that could be used to securely package, cache and deliver video content within system100. With reference now toFIG.2, the media player130or other client device suitably requests desired content from the CDN127or another source operating via network125(function202). If the content source127has packaged content ready for delivery (function204), then the pre-packaged and pre-stored content is simply delivered to the client device130. The media player device130is then able to jump directly to contacting the appropriate DRM service120to request appropriate decryption keys (functions226,227) and to play back the pre-packaged content (function230) using the received keys.

If the CDN127does not have pre-packaged content already cached for immediate delivery (function204), then a new package is created from content in the origin server112. CDN127(or another appropriate content delivery service on network125) suitably contacts the packaging service106of system100(function208) to initiate package creation. In various embodiments, message208will indicate the type of client device130that is requesting the content, and/or any other information to assist in obtaining content of appropriate quality, resolution, etc. for that particular device. The appropriate content files are requested (function210) from the origin server112and delivered to the packaging service (function211) for encryption, quality control and/or other packaging services as desired (function215). In various embodiments, the packaging service106includes a key store121that generates appropriate cryptographic keys (e.g., using any symmetric or asymmetric key generation techniques and appropriate key lengths) for encrypting the retrieved content. The cryptographic keys used to encrypt the content may be maintained in the key store121for subsequent retrieval; in various embodiments, keys are pushed to one or more DRM services120for a priori storage by the DRM service, as desired. In various embodiments, the encrypted content is assigned an identifier that allows convenient recognition and pairing to keys delivered through separate DRM services, as desired. The encrypted content is then delivered216to the CDN127for caching218. The encrypted content may be delivered to media player130(function220) via the CDN127, as shown inFIG.2, although equivalent embodiments could deliver the encrypted content directly from the packaging service106instead of passing through CDN127, as desired.

Many commercially-available CDNs127are able to process different types of DRM automatically, or DRM packaging may be part of the processing215performed by packaging server106. In various embodiments, the key store121or service106suitably delivers the appropriate cryptographic keys (and any associated identifiers for content encrypted with the generated key) to one or more DRM services120. In some examples, packages encrypted with the same key may be delivered to different types of devices that use different DRM providers. Each of the different client devices130is able to retrieve the key via its own DRM provider. To that end, key store121suitably delivers the generated keys and identifiers to the different DRM providers, each according to their own requirements. The NAGRA and SECURE MEDIA DRM services, for example, typically operate with a priori knowledge of keys, so keys are pushed to these services as soon as possible after they are generated, or in any event prior to the client devices130requesting the packaged content from CDN127. In the example illustrated inFIG.2, key222is delivered to CDN service120so that it can be stored (function224) for immediate delivery227when a subsequent request226is received from the client130. In other embodiments, CDN services120such as WIDEVINE, PLAY READY, FAIRPLAY and the like typically prefer to request keys from the key store121on an as-needed basis. In such cases, the DRM service120will typically request the key from key store121in response to a request226received from the client device130. In either event, the key can be securely delivered to the client device130(function227) so that the client can decrypt the content package and play back the desired media content (function230). As noted above, the same package of encrypted content stored at CDN may be delivered to multiple client devices130(including different types of client devices130using different DRM services120) as desired. This allows for very efficient delivery of media content using CDN127without incurring unnecessary overhead that would otherwise result from storing multiple copies of the same video (many of which would remain unused) of the same content with the CDN127.

The various processes, devices and systems described herein may be readily adapted for any number of equivalent environments and applications. For example, although the foregoing discussion frequently refers to video on demand services, equivalent embodiments could be used to process any other types of streaming video content, including content streamed from a remote service digital video recorder (RSDVR), placeshifting device, media server or the like. Any number of alternate but equivalent embodiments could be formulated as desired.

The term “exemplary” is used herein to represent one example, instance or illustration that may have any number of alternates. Any implementation described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other implementations. While several exemplary embodiments have been presented in the foregoing detailed description, it should be appreciated that a vast number of alternate but equivalent variations exist, and the examples presented herein are not intended to limit the scope, applicability, or configuration of the invention in any way. To the contrary, various changes may be made in the function and arrangement of elements described without departing from the scope of the claims and their legal equivalents.