JP7609515B2 - Content distribution using distributed ledger and AI-based transcoding technology - Google Patents

Description

CROSS-REFERENCE TO RELATED APPLICATIONS This application is a PCT International application claiming the benefit of U.S. Provisional Patent Application No. 63/082,677, filed September 24, 2020, entitled “Content Delivery Using Distibuted Ledger and AI-Based Transcoding Technologies,” and U.S. Provisional Patent Application No. 63/082,704, filed September 24, 2020, entitled “Content Delivery Using Distibuted Ledger and AI-Based Transcoding Technologies,” which are incorporated by reference in their entireties herein.

The complexities associated with adding content for distribution via a content delivery network (CDN) can result in increased overhead, unnecessary delays, and introduce the potential for human error. Additionally, the content received from a publisher or other content source may not be at a level of quality that would otherwise be available via a CDN for consumption by consumers. For example, the content may be at a lower resolution or have fewer audio channels.

It is with respect to these and other general considerations that the aspects disclosed herein are made. And, although relatively specific problems may be discussed, it should be understood that the examples are not limited to solving any particular problem identified in the background or elsewhere in this disclosure.

An example of the present disclosure relates to content delivery using distributed ledgers and AI-based transcoding techniques. In an example, content received from a content source is of lower quality or a different format compared to what can be delivered via a content delivery network (CDN). Thus, a set of AI-based transcoding models is evaluated to identify a transcoding model to use in transcoding the content. In some examples, multiple transcoding models are used for different portions of the content, for example to accommodate changing content types within the content (e.g., sports subparts, advertisement subparts, etc.). The transcoding may be performed at an edge node of the CDN, whereby the original lower quality content is transmitted within the CDN, thereby conserving CDN resources. Additionally, the transcoded content may be cached, whereby the AI-based transcoding techniques do not need to be applied in response to every request for the content.

This Summary is provided to introduce in a simplified form a selection of concepts further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additional aspects, features, and/or advantages of examples will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of the disclosure.

Non-limiting and non-exhaustive examples are described with reference to the following figures:

FIG. 1 illustrates an overview of an exemplary system in which aspects of content distribution using distributed ledgers and AI-based transcoding techniques may be implemented.

FIG. 1 illustrates an overview of an example distributed ledger engine.

FIG. 1 illustrates an overview of an exemplary content processor that performs AI-based transcoding.

FIG. 1 illustrates an overview of an example method for adding content to a CDN in accordance with the distributed ledger techniques described herein.

FIG. 1 illustrates an overview of an example method for processing triggers associated with content in accordance with the distributed ledger techniques described herein.

FIG. 1 illustrates an overview of an example method for validating content in accordance with the distributed ledger techniques described herein.

FIG. 1 illustrates an overview of an exemplary method for transcoding content in accordance with the AI-based transcoding techniques described herein.

FIG. 2 illustrates an overview of an example method for selecting a transcoding model in accordance with the AI-based transcoding techniques described herein.

FIG. 1 illustrates an example of a suitable operating environment in which one or more of the present embodiments may be implemented.

In the following detailed description, reference is made to the accompanying drawings, which form a part of this specification, and in which specific embodiments or examples are shown by way of illustration. These aspects may be combined, other aspects may be utilized, and structural changes may be made without departing from the disclosure. The embodiments may be practiced as methods, systems, or devices. Thus, the embodiments may take the form of a hardware implementation, an entirely software implementation, or an implementation combining software and hardware aspects. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of the disclosure is defined by the appended claims and their equivalents.

A content delivery network (CDN) includes a set of nodes that are used to process requests from client devices. For example, a CDN may deliver content from a content source, such as a content publisher, a video on demand (VOD) service, or a streaming platform. The content from the content provider is then accessed through the CDN by consumers using client devices. However, adding content to a CDN may have associated overhead, such as agreeing to terms and conditions (e.g., between the content source and the CDN), setting up contracts and billing arrangements (e.g., with the content source, for royalty payments, etc.), validating the received content and services provided, and finally processing payments.

In addition, the content received from the content source may be at a quality level that is less than the quality level that is available via the CDN. For example, the content source may provide "HD" content (e.g., having a resolution of 1280x720 or 1920x1080), while the CDN may deliver content in a higher resolution format such as "4K" (e.g., 3840x2160, 4096x2160, etc.) or "8K" (e.g., 7680x4320, 8192x5120, etc.). Similar issues may exist with respect to audio (e.g., as a standalone audio track, along with a video track/stream, etc.), where the content source provides audio with a lower number of channels (e.g., 2.0 vs. 5.1 or 7.1), a lower bit depth (e.g., 16-bit vs. 24-bit), a lower bit rate, and/or a different codec (e.g., a codec with a separate track vs. an object-based spatial audio codec) compared to what may be delivered by the CDN.

Accordingly, aspects of the present disclosure relate to content distribution using a distributed ledger and artificial intelligence-based (AI-based) transcoding techniques. In an example, a hash is generated for content received from a content source. The hash is incorporated into a distributed ledger (e.g., a block in a blockchain) as a content record, thereby ensuring that the hash is immutable and available for subsequent processing. For example, the stored hash may be used to perform content validation, thereby verifying the source of the content, the title of the content, and/or the actors/actresses, directors, or other artists associated with the content. Such metadata may be stored along with the content hash, or the metadata may be stored in a data store and associated with the content hash.

As another example, smart contracts may be generated and associated with the content hashes. For example, smart contracts may be for CDN services associated with the content (e.g., storage services, distribution services, content transcoding services, etc.), for licensing from the content source (e.g., payment for content playback based on content quality), and/or for royalties (e.g., music royalties, actor/actress royalties, director royalties, etc.). Triggers may be associated with the smart contracts such that the smart contracts are executed as a result of the triggers. Exemplary triggers include, but are not limited to, delivery of content via a CDN and initiation of content playback at a client device. Thus, the distributed ledger may be used to ensure that parties to smart contracts maintain their obligations and receive payment upon certain conditions (e.g., CDN service payment for delivery, royalty payment for content playback, etc.).

AI-based transcoding techniques are used to transcode content received from a content source that is of lower quality or a different format compared to what can be delivered via a CDN. For example, a CDN may deliver 4K or 8K content, whereby HD or standard definition (SD) content received from the content source is upscaled according to the AI-based transcoding techniques described herein. As a result, the content source does not need to purchase expensive video equipment or more powerful computer hardware to process higher quality video data, but instead can take advantage of such capabilities provided by the CDN. In addition, content may be delivered within the CDN (e.g., via an origin node to an edge node) in a lower resolution format (e.g., as received from the content source), and the content may be upscaled at the edge node prior to or concurrently with delivery to a client device. Such techniques may conserve bandwidth and storage requirements associated with delivering content via a CDN, while still providing a high-quality end-user experience.

As used herein, content includes, but is not limited to, video and/or audio as a stream or as a file, among other examples. For example, a video file or stream may include one or more audio tracks. As another example, a file or stream may be video only or audio only. A stream need not be a real-time or live stream, but may be a stream of pre-recorded content. For example, streaming content may be received by a CDN in subparts from a content source (e.g., using Dynamic Adaptive Streaming over HTTP (DASH) or Real-time Transport Protocol (RTP), etc.). A content source may be a publisher (e.g., a movie studio, a television studio, etc.), a VOD service, or a streaming platform, among other examples. Thus, while example content and content sources are described herein, it will be understood that the techniques may be applied to any of a variety of other content and content sources.

The content may be received from the content source via a website. For example, the website may allow a user to select content and specify associated metadata, such as a title and a list of actors/actresses, directors, or other associated artists. Other techniques may be used to receive the content from the content source, such as using an application programming interface (API). In some examples, the metadata may be obtained from another data source, such as a metadata repository managed by the content source or a third-party metadata repository. The content may then be transferred to a CDN, where a content record associated with the content is generated in the distributed ledger. The content record includes a content hash, which may be generated using any of a variety of hashing algorithms. Exemplary hashing algorithms include, but are not limited to, a Secure Hash Algorithm 2 (SHA-2) hash (e.g., SHA-256, SHA-512, etc.) or a RIPE Message Digest (RIPEMD) hash (e.g., RIPEMD-160, RIPEMD-256, etc.). A content hash may be generated based on the content itself, rather than based on metadata, either alone or in combination with the content.

The content hash may be stored in a distributed ledger, such as a block of a blockchain. In some examples, the content record further includes at least a portion of metadata associated with the content. In other examples, the metadata may be stored in a metadata repository or other data store and associated with the content hash. The metadata may be hashed as well, and the metadata hash may be stored as part of the content record, thereby allowing subsequent validation of the metadata to be performed. The content record may further include a timestamp associated with when the content was received by the CDN, and associated content source information (e.g., email address, billing address, company name, etc.).

One or more smart contracts associated with the content may be created. For example, the CDN and the content source may be parties to a smart contract, where the CDN receives compensation for delivering the content and the content source receives compensation for playing the content. In other examples, a smart contract may be entered into between the CDN or the content source and one or more other parties, such as musicians, actors/actresses, and directors, thereby allowing such parties to receive royalty payments. In some cases, smart contracts are used where the CDN is the only party to the contract, thereby allowing the CDN to maintain analytics in a distributed ledger based on the occurrence of triggers.

The smart contract may be part of the distributed ledger where the content hashes are stored, or in other examples, may be a different distributed ledger. For example, different distributed ledgers may be used for different parties (e.g., a different distributed ledger for each content source, using the same distributed ledger to track royalty payments to a particular artist, etc.). As another example, a content source may maintain its own distributed ledger, whereby a ledger gateway may be used to synchronize transactions between the content source ledger and the CDN ledger or provide indications about triggers, among other examples.

It will be understood that parties to a smart contract need not be actual users of the distributed ledger, but may instead act as a placeholder. For example, a royalty smart contract may be usable to generate an accounting of royalty payments associated with content, which may be provided to a content source or other party, which ultimately results in the payment of royalties. Thus, the smart contract and distributed ledger techniques described herein may not result in an actual exchange of value, but instead may facilitate accounting techniques for content delivered by a CDN.

The trigger may be any of a variety of events, such as events related to content delivery (e.g., transmission to a client device, transmission between origin and edge nodes, streaming or download activity, etc.) or content playback (e.g., playing/pausing content, fast forwarding/rewinding, early termination of playback, etc.). Once a trigger is identified, a content hash associated with the trigger is used to identify and execute an associated smart contract. Although example distributed ledger and smart contract techniques are described herein, it will be understood that any of a variety of other techniques may be used to generate and execute smart contracts associated with content delivered by a CDN. For example, a content hash need not be used, and an identifier associated with a smart contract may instead be associated with the content itself.

The distributed ledger may be processed to generate an accounting of payments due to the parties to the smart contracts therein. Such processing may be performed periodically (e.g., monthly, semi-annually, etc.) and an indication of the accounting may be provided to the content source or other parties. For example, the content source may receive the indication and then process royalty payments accordingly. As another example, the content source may receive the indication and process payments to a CDN for CDN services provided in delivering the content.

The distributed ledger may be used to perform validations on the content. For example, a consumer may wish to validate the source of the content, or in other instances, may wish to validate certain metadata associated with the content (e.g., that the actors/actresses who performed in the content were actually involved in its creation). Thus, the content may be hashed (e.g., at the consumer's client device, at a node in the CDN, etc.) and the content hash associated with the content may be identified in the distributed ledger. The content hash may be further used to identify the metadata associated with the content, thereby allowing a user to view the content source and associated metadata associated with the content.

As described above, content from a content source may be of lower quality or in a different format than what may be delivered by a CDN. Thus, AI-based transcoding techniques may be used to improve or modify the content. In an example, a set of transcoding models is used to perform upscaling or other video enhancement techniques. The set of transcoding models may be trained according to different content types. For example, different transcoding models may exist for action content, sports content, anime content, reality content, advertising content, and black and white content. Transcoding models are selected from the set of models according to a variety of criteria, including, but not limited to, content metadata (e.g., genre, actors/actresses, etc., which may indicate a particular content type), video analytics (e.g., bit rate, frame complexity, brightness/darkness, etc.), original content resolution, target content resolution, motion vectors, production year, format or codec type, and/or feedback received from consumers or other users.

In an example, multiple transcoding models are compared to determine which transcoding model should be applied. For example, object detection (e.g., inanimate objects, animated characters, actors/actresses, etc.) may be performed, whereby model processing results from multiple transcoding models may be compared based at least in part on how well detected objects are transcoded. The comparison may be automatic (e.g., detecting transcoding artifacts, comparing reference frames to transcoded frames, etc.) and/or manual (e.g., presenting multiple transcoded frames for user selection, asking for user feedback on encoding quality after or during playback, etc.). For example, a source frame may be downscaled, whereby the downscaled source frame is upscaled using multiple transcoding models to generate multiple transcoded frames. The transcoded frames may be compared to the original source frames to identify errors and quality loss, whereby the transcoding model exhibiting the highest quality (e.g., least errors, least quality loss, etc.) may be selected to transcode the content.

In examples, multiple transcoding models are used to transcode a single piece of content, where one model may be used for one subpart of the content while another model may be used for a different subpart. For example, a sports broadcast may be processed using a sports transcoding model, an advertising transcoding model, and a "talking heads" or commentary transcoding model. As described above, different transcoding models may be better suited for different content types. Transcoding model performance may be evaluated periodically during transcoding, whereby the transcoding model may change depending on the model performance for a given subpart. In some examples, the content resolution may change (e.g., between a sports segment of a broadcast and the advertisements therein), which may suggest that model performance should be reevaluated. In other examples, object detection may be used to determine the content of a video frame or to identify when an object has disappeared, both of which may indicate that transcoding model performance should be reevaluated. In some cases, the transcoding model applied to transcode the content may be re-evaluated on a frame-by-frame basis or according to any other level of granularity (e.g., every key frame or intra frame, after a certain number of frames, etc.). In addition, different transcoding models may be applied to intra frames, predicted frames, and/or bidirectional frames. It will be appreciated that a variety of techniques may be used to determine when to shift from one transcoding model to another to transcode the content. Similarly, such techniques need not be performed contemporaneously with the transcoding, but may be performed as a pre-processing operation to generate a transcoding "recipe" that specifies which transcoding model should be used to transcode which sub-parts of the content.

It will be appreciated that similar techniques may be applied to audio, e.g., to audio-only content or as part of video content. Similar to the video techniques described above, multiple audio transcoding models may be evaluated to determine which audio transcoding model should be applied. The evaluation may include identifying audio artifacts (e.g., audio artifacts within the range of human hearing), bitrate, errors, and/or quality loss resulting from transcoding audio. In examples, evaluating which audio transcoding model should be applied is performed contemporaneously with the video transcoding model evaluation discussed above. Thus, an event that results in a re-evaluation of the video transcoding model may also result in a re-evaluation of the audio transcoding model. Similarly, an event that results in a re-evaluation of the audio transcoding model may result in a re-evaluation of the video transcoding model. In other instances, the audio and video transcoding models are re-evaluated separately from one another. A video transcoding model may be associated with an audio transcoding model, such that both transcoding models are used to process the same type of content.

1A illustrates an overview of an example system 100 in which aspects of content distribution using distributed ledgers and AI-based transcoding techniques are implemented. As shown, the system 100 includes a content source 102, a gateway node 104, a gateway node 106, a local node 108, a client device 110, and a network 112. The content source 102, the gateway node 104, the gateway node 106, the local node 108, and the client device 110 are shown communicating through the network 112. The network 112 may include a local area network, a wide area network, one or more cellular networks, and/or the Internet, among other examples. The nodes 104, 106, and 108 are shown as including similar elements (e.g., data stores 118, 124, and 130; distributed ledger engines 120, 126, and 132; and content processors 122, 128, and 136). As a result, such similar aspects may not need to be described again in detail below for each node.

The content source 102 provides content to the CDN 140 (e.g., including gateway nodes 104 and 106 and local node 108, as shown by the dashed boxes) for distribution to consumers (e.g., using client application 138 on client device 110). For example, a computing device associated with the content source 102 may be used to access a website hosted by the CDN 140 (e.g., as may be provided by nodes 104, 106, or 108) to provide content in accordance with aspects described herein. Any of a variety of other techniques may be used to transmit content from the content source 102 to the CDN 140. It will be understood that in other examples, certain elements of the example CDN described with respect to system 100 may be provided by a third party and/or the functionality described herein with respect to certain elements may be distributed in accordance with any of a variety of other techniques.

The content source 102 is shown as including a data store 114 and a distributed ledger engine 116. In examples, the data store 114 stores the content that the content source 102 provides to the CDN 140. For example, the data store 114 stores content files and/or buffered content streams, among other examples. The distributed ledger engine 116 may manage a distributed ledger associated with the content source 102. For example, the content source 102 may maintain its own distributed ledger that includes records associated with the content it provides. In other examples, the content source may not include a distributed ledger engine.

Using the gateway node 104 as an example, content is received from the content source 102 and stored in the data store 118. The distributed ledger engine 120 generates a content record in the distributed ledger, where the content record may include a content hash, associated metadata, and/or any of a variety of other information. In an example, the content metadata is stored in the data store 118 and associated with the content hash. In some examples, the distributed ledger engine 120 generates one or more smart contracts associated with the content, which may be stored in the same or a different distributed ledger as the content record. In examples, the generated smart contracts are associated with the content hash and/or one or more triggers. In some examples, the distributed ledger engine 120 may act as a gateway between the CDN distributed ledger and the content source distributed ledger managed by the distributed ledger engine 116. For example, transactions may be synchronized in the content source ledger and the CDN ledger, or as another example, an indication may be provided about triggers identified in the CDN 140, among other examples.

The gateway node 104 may transmit content to the local node 108. The gateway nodes 104 and 106 may distribute content from the local node 108, such that content received from the content source 102 and provided to the local node 108 via the gateway node 104 may then be distributed by the gateway node 106. Thus, the CDN 140 may have a hierarchical or hub-and-spoke architecture, where certain nodes (e.g., nodes 104 and 106) are managed by other nodes (e.g., the local node 108). Although an example CDN structure is described herein, it will be understood that the nodes may be arranged in any of a variety of other structures in other examples.

The consumer uses a client application 138 of the client device 110 to access content of the CDN 140 (e.g., as may be provided to the CDN 140 by the content source 102). The client application 138 may be, among other examples, a web browser or an application developed or otherwise provided by the content source 102. Thus, the client device 110 communicates with one or more of the nodes 104, 106, and 108 to access the content. In some examples, the client device 110 may first communicate with the content source 102 (e.g., to access a list of content, such as may be provided via a website), after which the client device 110 may be directed to the CDN 140 to access a selected portion of the content provided by the CDN nodes 104, 106, and/or 108. As the content from the content source 102 is transferred within the CDN 140 and/or provided to the client device 110, one or more triggers may occur. For example, a consumer may generate a playback trigger via a client application 138 by requesting content from the CDN 140. The distributed ledger engine may then identify the trigger and execute an associated smart contract based at least in part on a hash of the associated content. For example, the distributed ledger engine 120, 126, or 132 may execute such aspects. Executing the smart contract may result in an update to the distributed ledger associated with the trigger. As another example, a trigger may occur when content is transmitted from the data store 130 of the local node 108 to the gateway node 106, whereby a smart contract is executed (e.g., by the distributed ledger engine 132 or 126) in association with bandwidth and/or storage usage associated with transmitting and storing the content.

In an example, the distributed ledger is processed to determine payments due to parties (e.g., content source 102, CDN 140, artist, etc.) of smart contracts therein. For example, the distributed ledger engine 132 of the local node 108 may perform such processing periodically (e.g., monthly, semi-annually, etc.) and an indication may be provided to the content source 102 and/or one or more other parties. For example, the content source 102 may receive the indication and then process a royalty payment accordingly. As another example, the content source 102 may receive the indication and process a payment to the CDN 140 for CDN services associated with delivering the content. In some instances, the distributed ledger engine 132 provides a website, API, or other method for accessing such aggregated payment information, managing smart contracts, and/or remitting payments. It will be appreciated that the gateway nodes 104 and 106 may perform similar aspects in other examples. As another example, the gateway nodes 104 and 106 may be managed by the local node 108, whereby the local node 108 performs the processing techniques described above on behalf of the gateway nodes 104 and 106.

In an example, content validation is requested. For example, a validation request is received from a client device 110, or in another example, the content is validated as a result of generating an accounting in the distributed ledger. As another example, a consumer may wish to validate the source of the content, or in another example, may wish to validate certain metadata associated with the content (e.g., that the actors/actresses who performed in the content were actually involved in its creation). Thus, a hash of the content is generated (e.g., at the client device 110, at nodes 104, 106, or 108, etc.) and compared to the content record in the distributed ledger. Such aspects may be performed by the distributed ledger engines 120, 126, and/or 132. If the generated content hash matches the stored content hash of the content record, the content is successfully validated. The content hash may be further used to identify metadata associated with the content, thereby allowing a user to view the content source and associated metadata associated with the content.

The content from the content source 102 may be of lower quality or in a different format than can be delivered by the CDN 140. Thus, the content processors 122, 128, and/or 136 may be used to improve or modify the content. As an example, the gateway node 104 (which received the content from the content source 102) uses the content processor 122 to perform the AI-based transcoding techniques described herein to generate a transcoded version of the content. The transcoded version may be distributed to other nodes in the CDN 140 (e.g., to the gateway node 106 via the local node 108). The content may be transcoded in response to receiving the content from the content source 102.

In another example, the original content is delivered to a node of the CDN 140, whereby the node 104, 106, or 108 uses the content processor 122, 128, or 136, respectively, to perform the AI-based transcoding technique in response to a request for the content (e.g., from the client device 110). For example, the request may include requested format information indicating a requested resolution, number of audio channels, bit rate, and/or color depth, among other examples. Thus, the requested format information may relate to video requested format information and/or audio requested format information. Additionally, delivering the original content within the CDN 140 and performing the transcoding at the node handling the request for the content may reduce the bandwidth associated with transferring the content within the CDN 140.

In some examples, at least a portion of the transcoded version of the content may be cached in a data store for a predetermined amount of time, such that the node need not generate a transcoded version in response to every request for the content, but instead may provide the cached transcoded version from the data store. In other examples, the transcoded version may be transmitted from one node to another (e.g., from the data store 130 of the local node 108 to the data store 118 of the gateway node 104), such that the receiving node does not need to transcode the content. It will be appreciated that the techniques described above with respect to the system 100 may be used in instances where the content source 102 provides pre-recorded and/or real-time content, among other examples.

The local node 108 is shown as further including a model manager 134. In the example, the transcoding models used by the content processors 122, 128, and 136 are managed by the model manager 134. For example, the content processor 122 may retrain or otherwise update the transcoding models used to transcode content based on implicit and/or explicit user feedback. Thus, the models may be provided to or obtained by the model manager 134, which may distribute the updated transcoding models to other content processors in the CDN 140. Thus, the transcoding models may be shared among the nodes 104, 106, and 108. Similarly, the model manager 134 may facilitate the sharing of transcoding recipes among the nodes 104, 106, and 108. For example, if the content processor 128 of the gateway node 106 has already analyzed which set of transcoding models should be used to transcode a particular portion of the content, the model manager 134 may obtain or otherwise access the transcoding recipe from the gateway node 106 and share the transcoding recipe with the content processors 122 and 136. Thus, the transcoded versions generated by the nodes 104, 106, and 108 may be similar as a result of using the same or similar transcoding recipe. It will be appreciated that other techniques may be used to synchronize the transcoding models and recipes. For example, a centralized data store may be used.

FIG. 1B illustrates an overview of an example distributed ledger engine 150. As shown, the distributed ledger engine 150 includes a hash generator 152, a smart contract processor 154, a trigger processor 156, and a content validator 158. In an example, the distributed ledger engine 150 is part of a CDN node, such as the distributed ledger engines 120, 126, and 132 of nodes 104, 106, and 108, respectively, in FIG. 1A.

The hash generator 152 generates the hashed content according to aspects described herein. For example, the content hash may be generated using any of a variety of hashing algorithms, such as a SHA-2 hash (e.g., SHA-256, SHA-512, etc.) or a RIPEMD hash (e.g., RIPEMD-160, RIPEMD-256, etc.). The hash generator 152 may generate the content hash based on the content itself, rather than based on metadata, either alone or in combination with the content. The hash may have multiple subparts, where a first subpart of the hash may uniquely identify the content, while one or more other subparts of the hash may be associated with the content resolution (e.g., different hashes for the subparts for HD, 4K, and/or 8K content) and/or the content source (e.g., a streaming platform may have a different hash subpart than the original content publisher). The content hash generated by the hash generator 152 may be stored as part of the content record in the distributed ledger. In some examples, hash generator 152 may also generate a hash of metadata associated with the content, which may also be stored as part of the content record. The content record may further include at least a portion of the metadata associated with the content or any of a variety of other information, including, but not limited to, a timestamp associated with when the content was received by the CDN (e.g., from content source 102 in FIG. 1A), and associated content source information (e.g., email address, billing address, company name, etc.).

The smart contract processor 154 of the distributed ledger engine 150 generates a smart contract associated with the content. As described above, smart contracts may be generated between any of a variety of parties, including, but not limited to, CDNs, content sources, and/or artists, musicians, actors/actresses, and directors, among others. The smart contract processor 154 may associate the generated smart contract with a content hash (e.g., as may have been generated by the hash generator 152). The smart contract processor 154 may store the smart contract in the same distributed ledger where the content records are stored, or in other examples, the smart contract may be in a different distributed ledger. For example, different distributed ledgers may be used for different parties (e.g., a different distributed ledger for each content source, using the same distributed ledger to track royalty payments to a particular artist, etc.). The smart contract processor 154 need not generate smart contracts between separate users, or in other examples, the parties to a smart contract need not be actual users, but instead may act as placeholders. For example, a royalty smart contract may be used to generate records of royalty payments, which may be provided to a content source or other party, which ultimately results in a royalty payment. As another example, the CDN is the only party to the contract, which allows the CDN to maintain analytics over the distributed ledger based on the occurrence of triggers.

Trigger processor 156 processes triggers and executes associated smart contracts. As described above, triggers may be any of a variety of events, such as events related to content delivery (e.g., transmission to a client device, transmission between origin and edge nodes, streaming or download activity, etc.) or content playback (e.g., playing/pausing content, fast forwarding/rewinding, early termination of playback, etc.). For example, trigger processor 156 may poll to determine whether an event has occurred (e.g., accessing log data, querying content from a data store, etc.) or may receive an indication (e.g., from a CDN node, from a client device, etc.). When trigger processor 156 identifies a trigger, the content hash associated with the trigger is used to identify and execute the associated smart contract (e.g., as may have been generated by smart contract processor 154).

The content validator 158 validates the content compared to the content hash in the distributed ledger. For example, the content validator 158 may receive a validation request (e.g., from a client device, such as client device 110 in FIG. 1A, as a result of processing a transaction). The validation request may include an indication to generate a hash for the particular content or may include a hash (e.g., as may be generated by the client device). In instances where a hash is not received as part of the request, the hash generator 152 generates a hash of the content. The content validator 158 then compares either the received hash or the generated hash to the hash in the distributed ledger to validate the content. Additional validation may be performed regarding the content source associated with the content and/or metadata, as described above.

FIG. 1C shows an overview of an example content processor 180 that performs AI-based transcoding. As shown, content processor 180 includes a model selector 182, an object detector 184, a transcoding engine 186, and a quality evaluator 188. In the example, content processor 180 is part of a CDN node, such as content processors 122, 128, and 136 of nodes 104, 106, and 108, respectively, in FIG. 1A. Content processor 180 transcodes content from a content source, such as content source 102 in FIG. 1A.

The model selector 182 selects a transcoding model to perform AI-based transcoding. For example, the model selector 182 selects a transcoding model from a set of models according to various criteria, including, but not limited to, content metadata (e.g., genre, actors/actresses, etc., which may indicate a particular content type), video analytics (e.g., bit rate, frame complexity, brightness/darkness, etc.), original content resolution, target content resolution, motion vectors, production year, format or codec type, and/or feedback received from consumers or other users. As described above, the set of transcoding models may be trained according to different content types. For example, different models may exist for action content, sports content, anime content, reality content, advertising content, and black and white content.

In an example, the model selector 182 compares multiple transcoding models to determine which transcoding model to apply. For example, the object detector 184 may identify inanimate objects, animated characters, and actors/actresses, among other objects, in a given video frame. The object detector 184 may apply any number and/or variety of object recognition machine learning models. For example, each object recognition machine learning model may be trained to recognize a particular subset of objects, or in other examples, the object recognition machine learning models are trained according to a particular type of content. It will be appreciated that the object detector 184 may apply any of a variety of other object detection techniques (e.g., identifying edges in a frame, analyzing motion across a set of frames, etc.).

The model selector 182 may then evaluate the model processing results from the multiple transcoding models using the quality evaluator 188 to determine how well the detected object was transcoded by each transcoding model. In an example, the quality evaluator 188 performs the comparison programmatically (e.g., by detecting transcoding artifacts, comparing a reference frame to the transcoded frame, etc.). For example, a source frame may be downscaled, whereby the downscaled source frame is upscaled using multiple transcoding models to generate multiple transcoded frames. The transcoded frames may be compared to the original source frame to identify errors and quality loss, whereby the transcoding model exhibiting the highest quality (e.g., least errors, least quality loss, etc.) may be selected to transcode the content. In another example, the quality evaluator 188 requests or otherwise receives explicit/implicit user input, for example, by generating a display of multiple transcoded frames in parallel for user selection.

The transcoding engine 186 transcodes the content to generate transcoded content. The transcoding engine 186 uses the transcoding model selected by the model selector 182 to perform the transcoding. In an example, multiple transcoding models are used to transcode the content, where one model may be used for a subpart of the content, while another model may be used for a different subpart. Thus, the transcoding model performance may be evaluated (e.g., by the quality evaluator 188) periodically during transcoding, so that the transcoding model may be changed (e.g., according to a selection made by the model selector 182) depending on the model performance for a given subpart. In some examples, the content resolution may change (e.g., between a sports segment of a broadcast and an advertisement therein), so that the transcoding engine 186 may determine that the model selector 182 should be used again to perform the model selection process. In other examples, the object detector 184 may be used to determine the content of a video frame or to identify when an object has disappeared, both of which may cause the model selector 182 to re-evaluate transcoding model performance. In some cases, the transcoding engine 186 applies different transcoding models to intra-frames, predicted frames, and/or bi-directional frames (each of which may be selected by the model selector 182). As described above, such techniques need not be performed contemporaneously with the transcoding, whereby the transcoding engine 186 instead utilizes a transcoding recipe that specifies which transcoding models should be used to transcode which sub-parts of the content.

FIG. 2A illustrates an overview of an example method 200 of adding content to a CDN in accordance with the distributed ledger techniques described herein. In an example, aspects of the method 200 are performed by a node of the CDN, such as node 104, 106, or 108 in FIG. 1A. As another example, aspects of the method 200 may be performed by a distributed ledger engine, such as distributed ledger engine 150 in FIG. 1B. The method 200 begins at operation 202, where an indication of content is received. The indication of content may be received from a content source, such as content source 102 in FIG. 1A. As another example, the indication of content may be received via a website of the CDN that allows a user (e.g., of a client device associated with the content source) to select content and specify associated metadata, such as a title and a list of actors/actresses, directors, or other associated artists. In another example, the metadata is stored in a metadata repository, and the content indication includes a reference to the metadata in the metadata repository. It will be appreciated that any of a variety of other techniques may be used to receive content from a content source, such as using an application programming interface (API).

Flow proceeds to operation 204 where a hash is generated for the content. In an example, the hash is generated by a hash generator, such as hash generator 152 in FIG. 1B. For example, the content hash may be generated based on the content itself, rather than based on metadata, either alone or in combination with the content. In an example, the content hash is part of the content record. The content record may store any of a variety of other information, such as hashes associated with the content metadata and/or the metadata itself.

At operation 206, a smart contract associated with the content is generated. The smart contract may be generated by a smart contract processor, such as smart contract processor 154 in FIG. 1B. The smart contract may be generated between any of a variety of parties, including, but not limited to, the CDN, the content source with which the indication received at operation 202 is associated, and/or the artist, musician, actor/actress, and director, among others. The smart contract generated at operation 206 may be associated with the content hash generated at operation 204. As described above, smart contracts need not be between separate users, or in other examples, the parties to the smart contract need not be actual users, but may instead function as placeholders. The smart contract may be associated with any of a variety of triggers that cause the execution of the smart contract, according to aspects described herein. Although operations 206 and 208 are described as generating a single smart contract, it will be understood that any number of smart contracts may be generated.

Moving to operation 208, the content hash and the smart contract are stored in a distributed ledger. In an example, the content record generated in operation 204 and the one or more smart contracts generated in operation 206 are stored in the same distributed ledger. As another example, the smart contract may be stored in a different distributed ledger than the content record. For example, different distributed ledgers may be used for different parties (e.g., different distributed ledgers for different content sources, the same distributed ledger used to track royalty payments to a particular artist, etc.). The flow ends at operation 208.

2B illustrates an overview of an example method 220 for processing triggers associated with content in accordance with the distributed ledger techniques described herein. In an example, aspects of the method 220 are performed by a node of a CDN, such as nodes 104, 106, or 108 in FIG. 1A. As another example, aspects of the method 220 may be performed by a distributed ledger engine, such as distributed ledger engine 150 in FIG. 1B. The method 220 begins at operation 222, where an indication of a trigger associated with a portion of content is received. In an example, the indication includes, among other information, a content hash of the content and a trigger type. The indication may be received by a trigger processor, such as trigger processor 156 in FIG. 1B. In other examples, the indication is not received, but instead is generated by a trigger processor.

In operation 224, content validation is performed. Content validation may be performed by a content validator, such as content validator 158 in FIG. 1B, which may perform aspects of method 240 described below in FIG. 2C. Content validation may include generating a hash of the content with which the trigger is associated and comparing the hash to a hash in the content record in the distributed ledger (e.g., as may have been generated by operations 204 and 208 of method 200 in FIG. 2A). In other cases, the content hash received in operation 222 is compared to the content hash in the distributed ledger to ensure that the hashes match. In some examples, operation 224 may be omitted or performed depending on the type of smart contract (e.g., a smart contract associated with payments may include content validation, while a smart contract associated with analytics may not).

Flow continues to operation 226 where a smart contract associated with the content is identified. In an example, the smart contract may be stored in the same distributed ledger as the content hash, thereby identifying the smart contract therein. In another example, the content hash may be used to identify a smart contract in a different distributed ledger, or as another example, the content record may include a reference to a smart contract in a different distributed ledger. It will therefore be appreciated that any of a variety of techniques may be used to identify a smart contract associated with a piece of content.

At operation 228, the smart contract identified at operation 226 is executed. In an example, executing the smart contract includes generating a new record in a distributed ledger associated with the smart contract, thereby enabling subsequent processing of the distributed ledger to generate reports (e.g., billing, analytics, etc.). In other examples, the smart contract may specify any of a variety of other actions including generating electronic communications, transmitting content in a CDN, and/or performing content transcoding. It will be appreciated that any number of actions may be performed at operation 228 as part of the smart contract execution. Flow ends at operation 228.

2C illustrates an overview of an example method 240 for validating content according to the distributed ledger techniques described herein. In an example, aspects of the method 240 are performed by a node of a CDN, such as node 104, 106, or 108 in FIG. 1A. As another example, aspects of the method 240 may be performed by a distributed ledger engine, such as distributed ledger engine 150 in FIG. 1B. The method 240 begins at operation 242, where a request for content validation is received. In an example, the request is received from a client device, such as client device 110 in FIG. 1A. In another example, the request is received from a smart contract processor, such as smart contract processor 154 in FIG. 1B, which may perform aspects of operation 224 in FIG. 2B. The request for content validation may include a content hash (e.g., as generated by the client device on which the request is received).

Flow proceeds to operation 244 where a hash of the content is generated. Operation 244 is illustrated using a dashed box to indicate that in some instances (e.g., instances where the content validation request includes the content hash) it may be omitted. Aspects of operation 244 may be performed by a hash generator, such as hash generator 152 in FIG. 1B. As discussed above, the hash may be generated based on the content itself, rather than being generated based on metadata, either alone or in combination with the content.

At operation 246, the stored hash is identified in the distributed ledger. The stored hash may be part of a content record according to aspects described herein. In examples, the content record may be associated with the content via a reference or other association. In some examples, validation may not be performed only on the content, but may also be performed on the metadata. In such examples, the stored metadata hash (which may be part of the content record, for example) may be identified as part of operation 246. It will be appreciated that any of a variety of other techniques may be used to identify the stored hash.

At decision 248, it is determined whether the hashes match. For example, the content hash received at operation 242 or the content hash generated at operation 244 may be compared to the content hash identified at operation 246. In an example, an exact match is used. In another example, the hash may have multiple subparts, where an exact match is used to compare the first subpart. Other subparts of the hash may be associated with the content resolution (e.g., different hashes for subparts for HD, 4K, and/or 8K content) and/or the content source (e.g., a streaming platform may have a different hash subpart than the original content publisher). As described above at operation 246, additional information may be evaluated as part of the determination of the metadata hash, etc. In some cases, the metadata itself may be stored as part of the content record, whereby matching techniques may be used to evaluate aspects of the metadata. It will be appreciated, therefore, that any of a variety of techniques may be used to determine whether the content hashes match, and that the match need not be an exact match.

If at decision 248 it is determined that the hashes do not match, the flow branches "No" to operation 250 where an indication is provided that the content is not validated. In an example, the indication further includes why validation failed (e.g., hash subparts did not match, certain metadata failed validation, etc.). The flow ends at operation 250.

However, if it is determined that the hashes match, the flow instead branches "Yes" to operation 252 where an indication is provided that the content has been validated. In some examples, the validation includes an indication of the more specific metadata that was validated (e.g., a non-exact match may indicate that the metadata is correct but incomplete, e.g., having the actor/actress first and last name rather than the full name, the entire release year rather than the exact date, etc.). The flow ends at operation 252.

FIG. 3A illustrates an overview of an example method 300 for transcoding content in accordance with the AI-based transcoding techniques described herein. In an example, aspects of method 300 are performed by a node of a CDN, such as node 104, 106, or 108 in FIG. 1A. As another example, aspects of method 300 may be performed by a content processor, such as content processor 180 in FIG. 1C.

Method 300 begins at operation 302, where an indication of content is received. The indication of content may be received from a content source when the content is being added to a CDN, such as content source 102 in FIG. 1A. In another example, the indication of content may be received from a client device when initiating playback, such as may be received from client device 110 in FIG. 1A. In an example, the indication of content includes a location where the content is stored and a requested resolution of the content, among other requested format information (e.g., number of audio channels, audio format, color depth, etc.). The requested format information may be different from the current format of the content, for example, the requested format information may specify a higher resolution or a greater number of channels. In some cases, the indication need not include the requested format information, which may instead be determined based on device characteristics (e.g., screen size, number of available speakers, available bandwidth, etc.).

Flow proceeds to operation 304, where a transcoding model is selected. In examples, aspects of operation 304 are performed by a model selector, such as model selector 182 of content processor 180 in FIG. 1C. For example, the transcoding model may be selected from a set of transcoding models according to a variety of criteria, including, but not limited to, content metadata (e.g., genre, actors/actresses, etc., which may indicate a particular content type), video analytics (e.g., bit rate, frame complexity, lightness/darkness, etc.), original content resolution, target content resolution, motion vectors, production year, format or codec type, and/or feedback received from consumers or other users. In some examples, operation 304 includes comparing multiple transcoding models to determine which transcoding model should be applied. Method 350 of FIG. 3B illustrates one example of such an aspect, and is discussed in more detail below.

In operation 306, the content is transcoded using the transcoding model selected in operation 304. The transcoding may be performed by a transcoding engine, such as transcoding engine 186. According to aspects described herein, multiple transcoding models may be used to transcode the content. For example, a first subpart may be transcoded according to the model selected in operation 304, after which the transcoding may pause and the flow may return to operation 304 to select a new transcoding model for a second subpart of the content. Such an aspect is illustrated by the arrow from operation 306 to operation 304. Thus, the transcoding model performance may be periodically evaluated by returning to operation 304, whereby the transcoding model may change depending on the model performance for a given subpart. In some examples, the content resolution may change, which may cause the flow to return to operation 304. In other examples, object detection may be used to determine the content of the video frame or to identify when an object has disappeared, which may cause the flow to return to operation 304. In some cases, the applied transcoding model may be re-evaluated on a frame-by-frame basis or according to any other level of granularity (e.g., every key frame or intra frame, after a predetermined number of frames, etc.). Additionally, although operations 304 and 306 are described as occurring sequentially, it will be understood that in other aspects, the subpart transcoding may occur in parallel, with different subparts being transcoded concurrently according to different transcoding models.

Finally, as previously described, different transcoding models may be applied to intra frames, predicted frames, and/or bidirectional frames. Therefore, operation 306 need not be limited to applying a single transcoding model to transcode the content. Rather, operation 306 may alternate between transcoding models while transcoding the content. As another example, a first transcoding model may be used to transcode a video track of the content, and a second transcoding model may be used to transcode an audio track of the content. It will be appreciated that a variety of techniques may be used to determine when to shift from one transcoding model to another transcoding model to transcode the content.

In other examples, operation 304 may be omitted and operation 306 may instead be performed based at least in part on a transcoding recipe that specifies which transcoding model should be used to transcode which sub-part of the content. The transcoding recipe may be associated with a requested resolution, number of audio channels, bit rate, and/or color depth, among other examples, such that the transcoding recipe may be identified based on requested format information provided in a request for the content (e.g., as received in operation 302). In such examples, method 300 including operation 304 may have been performed at another node, or as another example, operation 306 may be omitted such that the transcoding recipe is generated prior to any such transcoding.

Flow continues to operation 308, where the quality of the transcoded content is evaluated. Operation 308 may be performed after content transcoding is finished, or in other examples, may be performed periodically during transcoding. Aspects of operation 308 may be performed by a quality evaluator, such as quality evaluator 188 of content processor 180 in FIG. 1C. For example, the determination may be made programmatically (e.g., by detecting transcoding artifacts, comparing reference frames to the transcoded frames, etc.) and/or may be based on explicit/implicit user input. The user input may be a historical user input based on content previously transcoded using the same or similar transcoding model, where the user indicates the perceived quality of the transcoded content (e.g., quality on a scale of 1 to 5, a binary indication of whether the quality was good or not, etc.).

At decision 310, it is determined whether the quality meets a threshold. In an example, a predefined error rate or quality loss is compared to the evaluation performed at operation 308. In another example, a predefined score threshold is compared to a user input. It will be appreciated that any of a variety of other techniques and/or metrics and associated thresholds may be used to evaluate the quality. If at decision 310, it is determined that the quality threshold is not met, the flow branches "NO" back to operation 304, where a different transcoding model may be used to transcode the content. As used herein, a transcoding model may further include various settings or other variables, whereby a different transcoding model may include applying the same base transcoding model with settings and/or variables that are changed.

However, if it is determined that the transcoded content meets the quality threshold, flow instead branches "Yes" to operation 312 where the transcoded content is provided. In an example, the transcoded content is provided to a client device for playback to a consumer. In another example, the transcoded content is transmitted to a node of a CDN for storage and/or subsequent transmission to one or more consumers. Method 300 need not be limited to pre-recorded content, and similar techniques may be used for streaming or real-time content, among other examples. Method 300 ends at operation 312.

FIG. 3B illustrates an overview of an example method 350 for selecting a transcoding model in accordance with the AI-based transcoding techniques described herein. In an example, aspects of method 350 are performed by a node of a CDN, such as node 104, 106, or 108 in FIG. 1A. As another example, aspects of method 350 may be performed by a content processor, such as content processor 180 in FIG. 1C. Aspects of method 350 may be performed as part of operation 304 of method 300 in FIG. 3A.

Method 350 begins at operation 352, where a content frame is selected. In an example, the selected content frame is a frame that is to be transcoded by a content processor, such as one that performs aspects of method 300 in FIG. 3A. In another example, the selected content frame is a key frame or a frame determined to be representative of the content. For example, the frame may be selected as a result of having a relatively high degree of motion or detail, among other examples.

In operation 354, objects are detected in the selected content frames. Aspects of operation 354 may be performed by an object detector, such as object detector 184 in FIG. 1C. Operation 354 may include identifying one or more inanimate objects, animated characters, and actors/actresses, among other objects. The selected content frames may be processed according to any number and/or variety of object recognition machine learning models. For example, each object recognition machine learning model may be trained to recognize a particular subset of objects, or in other examples, the object recognition machine learning models are trained according to a particular type of content. It will be appreciated that any of a variety of other object detection techniques (e.g., identifying edges in frames, analyzing motion over a set of frames, etc.) may be used. Operation 354 is illustrated using a dashed box to indicate that in other examples, operation 354 may be omitted such that the model selection technique of method 350 does not have to evaluate model performance specifically with respect to the detected object.

Flow proceeds to operation 356 where the resolution of the content frame is reduced. In an example, the reduced resolution is determined based on the amount of visual data to be generated using the AI-based transcoding techniques described herein. For example, upscaling 1080p HD (e.g., 1920x1080) content to 4K content (e.g., 3840x2160) results in a four-fold increase in pixel data. Thus, a 1080p HD source may be downscaled by a factor of four (e.g., to 960x540) in operation 356. It will be appreciated that any number of other downscaled resolutions may be used. Operation 356 is illustrated using a dashed box to indicate that operation 356 may be omitted in other examples. For example, operation 356 may be omitted if the model processing results are compared to each other without involving a comparison to the source content frame.

In operation 358, the content frame is processed using a set of transcoding models. In an example, processing the content frame includes upscaling the downscaled content frame (e.g., as generated in operation 356) using each transcoding model to result in a transcoded content frame having the same or similar resolution as the original content frame selected in operation 352. In some cases, transcoding the content frame includes utilizing the same base model but modifying settings or variables used to transcode the content frame. The set of transcoding models used in operation 358 may be at least a subset of the transcoding models used by the CDN to transcode the content. In some examples, the set of transcoding models is selected according to a variety of criteria, including, but not limited to, content metadata (e.g., genre, actors/actresses, etc., which may indicate a particular content type), video analytics (e.g., bit rate, frame complexity, brightness/darkness, etc.), original content resolution, target content resolution, motion vectors, production year, format or codec type, and/or feedback received from consumers or other users.

Flow proceeds to operation 360, where the set of transcoded content frames are scored according to quality. In examples, the transcoded content frames may be scored programmatically (e.g., by detecting transcoding artifacts, comparing reference frames to the transcoded frames, etc.) and/or based on explicit/implicit user input. The transcoded content frames may be scored individually, scored relative to each other, and/or scored based on the content frames selected in operation 352. As discussed above, the user input may be received from a display of parallel transcoded frames, or may be historical user input based on previously transcoded content using the same or similar transcoding model, among other examples. In examples, aspects of operation 360 are performed by a quality evaluator, such as quality evaluator 188 of content processor 180 in FIG. 1C.

At operation 362, an indication of the transcoding model having the highest score is provided. In an example, the indication is provided to a transcoding engine, such as transcoding engine 186 of content processor 180 in FIG. 1C. As an example, the indication may be used at operation 306 of method 300 in FIG. 3A to transcode the content. In an example, the indication includes the transcoded content frame, such that the transcoding engine does not need to re-transcode the content frame selected at operation 352. It will be appreciated that while method 350 is described as selecting and processing a single content frame, in other examples, multiple content frames may be processed. For example, method 350 may determine a transcoding model for a set of frames, after which the model selection process may be performed again to identify the same or a different transcoding model. In such an example, the indication includes an indication of the content sub-part for which the transcoding model should be used (e.g., according to number of frames, timestamp, etc.). The flow ends at operation 362.

Figure 4 illustrates an example of a suitable operating environment 400 in which one or more of the present embodiments may be implemented. This is merely one example of a suitable operating environment and is not intended to suggest any limitations as to scope of use or functionality. Other well-known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics such as smartphones, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like.

In its most basic configuration, the operating environment 400 may typically include at least one processing unit 402 and memory 404. Depending on the exact configuration and type of computing device, the memory 404 (which stores, among other things, APIs, programs, etc., and/or other components or instructions that implement or execute the systems and methods disclosed herein) may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.), or some combination of the two. This most basic configuration is illustrated in FIG. 4 by dashed line 406. Additionally, the environment 400 may include storage devices (removable 408 and/or non-removable 410), including but not limited to magnetic or optical disks or tapes. Similarly, the environment 400 may have input devices 414, such as a keyboard, mouse, pen, voice input, etc., and/or output devices 416, such as a display, speakers, printer, etc. One or more communication connections 412, such as a LAN, WAN, point-to-point, etc., may also be included in the environment.

The operating environment 400 may include at least some form of computer-readable media. Computer-readable media may be any available media that can be accessed by the processing unit 402 or other devices that comprise the operating environment. For example, computer-readable media may include computer storage media and communication media. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media may include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store the desired information. Computer storage media may not include communication media.

Communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" may mean a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. For example, communication media may include wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

Operating environment 400 may be a single computer operating in a networked environment using logical connections to one or more remote computers. The remote computers may be personal computers, servers, routers, network PCs, peer devices or other common network nodes, and typically include many or all of the elements described above, as well as others not so mentioned. The logical connections may include any method supported by the available communications media. Such networking environments are common in offices, enterprise-wide computer networks, intranets and the Internet.

The different aspects described herein may be utilized using software, hardware, or a combination of software and hardware to implement and execute the systems and methods disclosed herein. Although specific devices are described throughout this disclosure as performing specific functions, those skilled in the art will recognize that these devices are provided for illustrative purposes and that other devices may be utilized to perform the functions disclosed herein without departing from the scope of the disclosure.

As mentioned above, a number of program modules and data files may be stored in the system memory 404. While executing on the processing unit 402, the program modules (e.g., applications, input/output (I/O) management, and other utilities) may perform processes that include one or more of the stages of the operational methods described herein, such as, but not limited to, the methods shown in Figures 2A-2C and 3A-3B.

Additionally, examples of the present invention may be practiced in electrical circuits including discrete electronic elements, packaged or integrated electronic chips including logic gates, circuits utilizing a microprocessor, or on a single chip including electronic elements or a microprocessor. For example, examples of the present invention may be practiced via a system-on-chip (SOC) in which each or many of the components shown in FIG. 4 may be integrated onto a single integrated circuit. Such an SOC device may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all of which are integrated (or "burned") onto a chip substrate as a single integrated circuit. When operating via an SOC, the functions described herein may be operated via application-specific logic integrated with other components of the operating environment 400 on a single integrated circuit (chip). Examples of the present disclosure may be practiced using other technologies capable of performing logical operations such as AND, OR, and NOT, including, for example, but not limited to, mechanical, optical, fluidic, and quantum technologies. Additionally, examples of the present invention may be practiced within a general-purpose computer or in any other circuit or system.

This disclosure has described several aspects of the technology with reference to the accompanying drawings, in which only some of the possible embodiments are shown. However, other aspects may be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of possible embodiments to those skilled in the art.

Although specific aspects have been described herein, the scope of the technology is not limited to those specific embodiments. Those skilled in the art will recognize other embodiments or improvements that are within the scope and spirit of the technology. Thus, specific structures, operations, or media are disclosed only as exemplary embodiments. The scope of the technology is defined by the following claims and any equivalents therein.
[Other possible items]
[Item 1]
13. A system comprising:
at least one processor; and a memory operatively connected to the at least one processor and storing instructions that, when executed by the at least one processor, cause the system to perform a set of operations, the set of operations being:
receiving a request for content from a content delivery network (CDN) from a client device, where the request for content includes requested format information indicating a requested resolution that is different from a resolution of the content;
determining a transcoding model from a set of transcoding models for transcoding the content;
transcoding at least a portion of the content using the determined transcoding model to generate transcoded content having the requested resolution; and providing the transcoded content to the client device in response to a request for the content.
[Item 2]
Determining the transcoding model comprises:
selecting a content frame from the content;
downscaling the content frame;
The downscaled content frame:
2. The system of claim 1, comprising: processing using a first transcoding model to generate a first transcoded frame; and a second transcoding model to generate a second transcoded frame; and evaluating the first transcoded frame and the second transcoded frame based on the content frame to determine the transcoding model, where the transcoding model is either the first transcoding model or the second transcoding model.
[Item 3]
3. The system of claim 2, wherein determining the transcoding model further comprises recognizing objects of the content frames; and the first transcoded frame and the second transcoded frame are further evaluated based at least in part on the recognized objects of the content frames to determine the transcoding model.
[Item 4]
The transcoding model is a first transcoding model;
the at least one portion of the content is a first portion of the content; and the set of actions is:
2. The system of claim 1, further comprising: determining a second transcoding model for transcoding the content from a set of transcoding models; and transcoding a second portion of the content using the determined transcoding model to further generate the transcoded content having the requested resolution.
[Item 5]
the client device is a first client device;
the request for content is a first request for content; and the set of actions is:
storing the transcoded content in a data store;
13. The system of claim 1, further comprising: receiving a second request for the content from a second client device; and providing the transcoded content from the data store in response to the second request for the content.
[Item 6]
The set of actions are:
2. The system of claim 1, further comprising: receiving a request for the transcoded content from a node of the CDN; and providing the transcoded content to the node of the CDN.
[Item 7]
2. The system of claim 1, wherein the requested format information includes at least one of audio requested format information or video requested format information.
[Item 8]
1. A method for transcoding content using a transcoding recipe, comprising:
From a node of a content delivery network (CDN), the content and:
receiving a transcoding recipe indicating: a first transcoding model for a first sub-part of the content; and a second transcoding model for a second sub-part of the content;
transcoding the first sub-part of the content using the first transcoding model to generate a first transcoded sub-part;
transcoding the second subpart of the content using the second transcoding model to generate a second transcoded subpart; and providing transcoded content including the first transcoded subpart and the second transcoded subpart to a client device.
[Item 9]
receiving a request for the content from the client device;
9. The method of claim 8, further comprising: wherein the first sub-part and the second sub-part are transcoded based at least in part on receiving the request.
[Item 10]
10. The method of claim 9, wherein the request for the content includes information of a requested format; and the transcoding recipe is determined based at least in part on the information of the requested format.
[Item 11]
the client device is a first client device;
The method comprises:
storing the transcoded content in a data store;
9. The method of claim 8, further comprising: receiving a request for the content from a second client device; and providing the transcoded content from the data store in response to the request for the content.
[Item 12]
9. The method of claim 8, wherein the first sub-part of the content is a video track of the content; and the second sub-part of the content is an audio track of the content.
[Item 13]
9. The method of claim 8, further comprising: receiving a request for the transcoded content from a node of the CDN; and providing the transcoded content to the node of the CDN.
[Item 14]
1. A method for transcoding content from a content provider, comprising:
receiving a request for content from a content delivery network (CDN) from a client device, where the request for content includes requested format information indicating a requested resolution that is different from a resolution of the content;
determining a transcoding model for transcoding the content from a set of transcoding models;
transcoding at least a portion of the content using the determined transcoding model to generate transcoded content having the requested resolution; and providing the transcoded content to the client device in response to a request for the content.
[Item 15]
The step of determining the transcoding model comprises:
selecting a content frame from the content;
downscaling the content frame;
The downscaled content frame:
15. The method of claim 14, comprising: processing using a first transcoding model to generate a first transcoded frame; and a second transcoding model to generate a second transcoded frame; and evaluating the first transcoded frame and the second transcoded frame based on the content frame to determine the transcoding model, where the transcoding model is either the first transcoding model or the second transcoding model.
[Item 16]
16. The method of claim 15, wherein determining the transcoding model further comprises recognizing objects of the content frames; and the first transcoded frame and the second transcoded frame are further evaluated based at least in part on the recognized objects of the content frames to determine the transcoding model.
[Item 17]
The transcoding model is a first transcoding model;
the at least one portion of the content is a first portion of the content; and the method includes:
determining a second transcoding model for transcoding the content from a set of transcoding models; and transcoding a second portion of the content using the determined transcoding model to further generate the transcoded content having the requested resolution.
[Item 18]
the client device is a first client device;
the request for content is a first request for content; and the method includes:
storing the transcoded content in a data store;
15. The method of claim 14, further comprising: receiving a second request for the content from a second client device; and providing the transcoded content from the data store in response to the second request for the content.
[Item 19]
15. The method of claim 14, further comprising: receiving a request for the transcoded content from a node of the CDN; and providing the transcoded content to the node of the CDN.
[Item 20]
15. The method of claim 14, wherein the requested format information includes at least one of audio requested format information or video requested format information.
[Item 21]
13. A system comprising:
at least one processor; and a memory operatively connected to the at least one processor and storing instructions that, when executed by the at least one processor, cause the system to perform a set of operations, the set of operations being:
receiving an indication of the content from a content source;
storing said content in a data store;
generating a content hash based on the content;
storing the content hash as a content record in a distributed ledger;
receiving a request for the content from a client device; and providing at least a portion of the content from the data store in response to the request.
[Item 22]
The set of actions are:
generating a smart contract associated with the content, where the smart contract is associated with a trigger;
22. The system of claim 21, further comprising: identifying the trigger based on the request for the content from the client device; and in response to identifying the trigger, executing the smart contract to generate a new record in the distributed ledger.
[Item 23]
The set of actions are:
23. The system of claim 22, further comprising: processing the distributed ledger to identify at least the new record; and generating accounting indications associated with the content based at least in part on the new record; and providing the accounting indications to the content source.
[Item 24]
The content hash is a first content hash and the set of actions is:
receiving a validation request from the client device, the validation request including a second content hash;
22. The system of claim 21, further comprising: determining that the content is validated if the first content hash matches the second content hash; and, in response to the validation request, providing an indication that the content is validated.
[Item 25]
22. The system of claim 21, wherein the indication of the content further includes metadata associated with the content; and the metadata is not used to generate the content hash.
[Item 26]
26. The system of claim 25, wherein at least a portion of the metadata is stored in the content record.
[Item 27]
26. The system of claim 25, wherein at least a portion of the metadata is stored in a metadata repository and associated with the content hash.
[Item 28]
1. A method for generating a smart contract for content delivery network (CDN) content, comprising:
receiving an indication of the content from a content source;
generating a smart contract associated with the content, where the smart contract is associated with a trigger;
storing the smart contract in a distributed ledger;
receiving a request for the content from a client device;
identifying the trigger based on the request for the content from the client device;
in response to identifying the trigger, executing the smart contract to generate a new record in the distributed ledger; and in response to the request, providing at least a portion of the content.
[Item 29]
30. The method of claim 28, further comprising: processing the distributed ledger to identify at least the new records; and generating accounting indications associated with the content based at least in part on the new records; and providing the accounting indications to the content sources.
[Item 30]
generating a content hash based on the content;
30. The method of claim 28, further comprising storing the content hash as a content record in the distributed ledger.
[Item 31]
The content hash is a first content hash, and the method comprises:
receiving a validation request from the client device, the validation request including a second content hash;
31. The method of claim 30, further comprising: determining that the content is validated if the first content hash matches the second content hash; and providing an indication that the content is validated in response to the validation request.
[Item 32]
31. The method of claim 30, wherein the indication of the content further includes metadata associated with the content; and the metadata is not used to generate the content hash.
[Item 33]
30. The method of claim 28, wherein the content is a subpart of streaming content from the content source.
[Item 34]
1. A method of adding content to a content delivery network (CDN), comprising:
receiving an indication of the content from a content source;
storing said content in a data store;
generating a content hash based on the content;
storing the content hash as a content record in a distributed ledger;
receiving a request for the content from a client device; and providing at least a portion of the content from the data store in response to the request.
[Item 35]
generating a smart contract associated with the content, where the smart contract is associated with a trigger;
35. The method of claim 34, further comprising: identifying the trigger based on the request for the content from the client device; and in response to identifying the trigger, executing the smart contract to generate a new record in the distributed ledger.
[Item 36]
36. The method of claim 35, further comprising: processing the distributed ledger to identify at least the new records; and generating accounting indications associated with the content based at least in part on the new records; and providing the accounting indications to the content sources.
[Item 37]
The content hash is a first content hash, and the method comprises:
receiving a validation request from the client device, the validation request including a second content hash;
35. The method of claim 34, further comprising: determining that the content is validated if the first content hash matches the second content hash; and providing an indication that the content is validated in response to the validation request.
[Item 38]
35. The method of claim 34, wherein the indication of the content further includes metadata associated with the content; and the metadata is not used to generate the content hash.
[Item 39]
40. The method of claim 38, wherein at least a portion of the metadata is stored in the content record.
[Item 40]
40. The method of claim 38, wherein at least a portion of the metadata is stored in a metadata repository and associated with the content hash.

Claims (12)

13. A system comprising:
at least one processor; and a memory operatively connected to the at least one processor and storing instructions that, when executed by the at least one processor, cause the system to perform a set of operations, the set of operations being:
receiving a request for content from a content delivery network (CDN) from a client device, where the request for content includes requested format information indicating a requested resolution that is different from a resolution of the content;
determining a transcoding model from a set of transcoding models for transcoding the content;
transcoding at least a portion of the content using the determined transcoding model to generate transcoded content having the requested resolution; and providing the transcoded content to the client device in response to a request for the content ,
Determining the transcoding model comprises:
selecting a content frame from the content;
downscaling the content frame;
The downscaled content frame:
a first transcoding model that generates a first transcoded frame; and
A second transcoding model for generating a second transcoded frame.
Processing using
evaluating the first transcoded frame and the second transcoded frame based on the content frame to determine the transcoding model, where the transcoding model is either the first transcoding model or the second transcoding model.
Including, the system. 2. The system of claim 1, wherein determining the transcoding model further comprises recognizing objects of the content frames; and the first transcoded frame and the second transcoded frame are further evaluated based at least in part on the recognized objects of the content frames to determine the transcoding model . The transcoding model is a first transcoding model;
the at least one portion of the content is a first portion of the content; and the set of actions is:
3. The system of claim 1, further comprising: determining a second transcoding model for transcoding the content from a set of transcoding models; and transcoding a second portion of the content using the determined transcoding model to further generate the transcoded content having the requested resolution. the client device is a first client device;
the request for content is a first request for content; and the set of actions is:
storing the transcoded content in a data store;
The system of any one of claims 1 to 3, further comprising: receiving a second request for the content from a second client device; and providing the transcoded content from the data store in response to the second request for the content. The set of actions are:
The system of claim 1 , further comprising: receiving a request for the transcoded content from a node of the CDN; and providing the transcoded content to the node of the CDN. The system of any one of claims 1 to 5 , wherein the requested format information includes at least one of audio requested format information or video requested format information. 1. A method for transcoding content from a content provider, comprising:
receiving a request for content from a content delivery network (CDN) from a client device, where the request for content includes requested format information indicating a requested resolution that is different from a resolution of the content;
determining a transcoding model for transcoding the content from a set of transcoding models;
transcoding at least a portion of the content using the determined transcoding model to generate transcoded content having the requested resolution; and providing the transcoded content to the client device in response to a request for the content ,
The step of determining the transcoding model comprises:
selecting a content frame from the content;
downscaling the content frame;
The downscaled content frame:
a first transcoding model that generates a first transcoded frame; and
A second transcoding model for generating a second transcoded frame.
processing using
evaluating the first transcoded frame and the second transcoded frame based on the content frame to determine the transcoding model, where the transcoding model is either the first transcoding model or the second transcoding model.
The method comprising: 8. The method of claim 7, wherein determining the transcoding model further comprises recognizing objects in the content frames; and the first transcoded frame and the second transcoded frame are further evaluated based at least in part on the recognized objects in the content frames to determine the transcoding model . The transcoding model is a first transcoding model;
the at least one portion of the content is a first portion of the content; and the method includes:
9. The method of claim 7 or 8, further comprising: determining a second transcoding model from a set of transcoding models for transcoding the content; and transcoding a second portion of the content using the determined transcoding model to further generate the transcoded content having the requested resolution. the client device is a first client device;
the request for content is a first request for content; and the method includes:
storing the transcoded content in a data store;
The method of claim 7 , further comprising: receiving a second request for the content from a second client device; and providing the transcoded content from the data store in response to the second request for the content. The method of claim 7 , further comprising: receiving a request for the transcoded content from a node of the CDN; and providing the transcoded content to the node of the CDN . The method of any one of claims 7 to 11 , wherein the requested format information comprises at least one of audio requested format information or video requested format information.