KR20230073314A - Content Delivery Using Distributed Ledger and AI-Based Transcoding Technology - Google Patents

Abstract

Examples of the invention relate to content delivery using distributed ledgers and AI-based transcoding technology. In examples, content is received from a content source by a content delivery network (CDN). The content may be of lower quality or in a different format than that distributed through the CDN. Accordingly, a transcoding model is identified and used to transcode the content. To adapt to changing content types (eg, sports sub-portions, advertising sub-portions, etc.), multiple transcoding models may be used for different content portions. Transcoding can occur at the edge node so that the original content is transmitted within the CDN, conserving resources. Additionally, transcoded content may be cached so that the content does not have to be transcoded in response to every request.

Description

Content Delivery Using Distributed Ledger and AI-Based Transcoding Technology

CROSS REFERENCES TO RELATED APPLICATIONS

This application is filed on September 24, 2020 and entitled "Content Delivery Using Distributed Ledger and AI-Based Transcoding Technologies," and is filed on September 24, 2020 and claims the invention is a PCT International Application claiming priority to U.S. Provisional Application Serial No. 63/082,704 entitled “Content Delivery Using Distributed Ledger and AI-Based Transcoding Technologies,” which are hereby incorporated by reference in their entirety.

The complexity associated with adding content for distribution through a content distribution network (CDN) increases overhead, introduces unnecessary delay, and introduces the potential for human error. Additionally, content received from publishers or other content sources may not be at a quality level that may be available for consumption via a CDN by consumers. For example, the content may be of lower resolution or may have fewer audio channels.

The aspects disclosed herein have been made with respect to these and other general considerations. Further, although relatively specific problems may be discussed, it should be understood that the examples should not be limited to solving specific problems identified in the background section or elsewhere herein.

Examples of the invention relate to content delivery using distributed ledgers and AI-based transcoding technology. In examples, content received from a content source may be of a lower quality or a different format than may be distributed through a content delivery network (CDN). Accordingly, a set of AI-based transcoding models are evaluated to identify a transcoding model that will transcode this content. In some examples, multiple transcoding models are used for different portions of content, for example to adapt to changing content types within the content (eg, sports subportions, advertising subportions, etc.). Transcoding may occur at the edge nodes of the CDN, such that the original low-quality content is transmitted within the CDN to conserve CDN resources. Additionally, transcoded content may be cached so that AI-based transcoding techniques do not have to be applied in response to every request for the content.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description of Example Embodiments. 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 the examples will be set forth in part in the detailed description that follows, and in part will become apparent from the detailed description, or may be learned by practicing the invention.

Non-limiting and non-exhaustive examples are described with reference to the following figures.
1A illustrates an overview of an example system in which aspects of content delivery using a distributed ledger and AI-based transcoding technology are performed.
1B illustrates an overview of an example distributed ledger engine.
1C illustrates an overview of an example content processor for performing AI-based transcoding.
2A illustrates an overview of an example method for adding content to a CDN in accordance with the distributed ledger techniques described herein.
2B illustrates an overview of an example method for processing a trigger associated with content in accordance with the distributed ledger techniques described herein.
2C illustrates an overview of a method for authenticating content according to the distributed ledger techniques described herein.
3A illustrates an overview of an example method for transcoding content according to the AI-based transcoding technology described herein.
3B illustrates an overview of an example method for selecting a transcoding model according to the AI-based transcoding technology described herein.
4 illustrates an example of a suitable operating environment in which one or more of the embodiments of the invention may be implemented.

In the detailed description of the invention that follows, reference is made to the accompanying drawings, which form a part of the specification and show specific embodiments or examples by way of example. These aspects may be combined, other aspects may be utilized, and structural changes may be made without departing from the invention. Embodiments may be practiced as a method, system or device. Accordingly, embodiments may take the form of hardware implementations, entirely software implementations, or implementations that combine software and hardware aspects. Therefore, the detailed description set forth below is not to be construed in a limiting sense, and the scope of the present invention is defined by the appended claims and their equivalents.

A content delivery network (CDN) includes a set of nodes used to process requests from client devices. For example, a CDN may distribute content from a content source, such as a content publisher, a video-on-demand (VOD) service, or a streaming platform. Thus, content from content is accessed via the CDN by consumers using client devices. However, adding content to a CDN involves associated overhead, such as agreeing to terms and conditions (e.g., between the content source and the CDN), arranging agreements and billing arrangements (e.g., the content source and, for royalty payments, etc.), authenticating received content and provided services, and finally processing payments.

Additionally, the content received from the content source may be at a lower quality level than what is available through the CDN. For example, a content source may provide "HD" content (e.g., with a resolution of 1280x720 or 1920x1080), whereas a CDN may provide content in a higher resolution format, such as "4K" (e.g. , 3840x2160, 4096x2160, etc.) or “8K” (eg, 7680x4320, 8192x5120, etc.). A similar problem may exist for audio (eg as a standalone audio track with a video track/stream, etc.), where the content source has a lower channel count than can be transported by the CDN (eg 2.0 vs. 5.1 or 7.1), lower bit depth (eg, 16-bit vs. 24-bit), lower bitrate, and/or different codec (eg, codec with discrete tracks vs. object-based spatial audio) codec).

Accordingly, aspects of the present invention relate to content delivery using distributed ledgers and AI-based transcoding technologies. In examples, a hash is generated for content received from a content source. A hash is contained within a distributed ledger (e.g., a block in a blockchain) as a record of content, thereby ensuring that the hash is immutable and available for subsequent processing. For example, the stored hash may be used to perform content authentication, thereby verifying the source of the content, the title of the content, and/or the heroine/heroine, director, or other artist associated with the content. Such metadata may be stored with the content hash, or the metadata may be stored within the data store and associated with the content hash.

As another example, a smart contract may be created and associated with a content hash. For example, smart contracts are for content-related CDN services (e.g., storage services, delivery services, content transcoding services, etc.), licensing from content sources (e.g., payment based on content quality). for payment), and/or for royalties (eg, music royalties, heroine/heroine royalties, director royalties, etc.). A trigger can be associated with a smart contract so that the smart contract is executed as a result of the trigger. Example triggers include, but are not limited to, transmission of content via a CDN and initiation of content playback on a client device. Thus, distributed ledgers can be used to ensure that participants abide by their obligations according to smart contracts and receive payment under certain conditions (eg, CDN service payment for transmission, royalty payment for content playback, etc.).

AI-based transcoding techniques are used to transcode content received from a content source that is of a lower quality or a different format than can be transmitted over a CDN. For example, a CDN may distribute 4K or 8K content such that HD or standard definition (SD) content received from a content source is upscaled according to the AI-based transcoding techniques described herein. As a result, content sources do not need to purchase expensive video equipment or more powerful computer hardware to process higher quality video data, but can instead utilize these functionality provided by the CDN. Additionally, content may be transmitted within the CDN (e.g., via the origin node to the edge node) in a lower resolution format (e.g., as received from the content source), before the content is transmitted to the client device or At the same time, it can be upscaled at the edge node. This technique can conserve the bandwidth and storage requirements associated with delivering content through 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 that is a stream or file, among other examples. For example, a video file or stream may contain one or more audio tracks. As another example, a file or stream may be video-only or audio-only. The 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 from a content source as a sub-portion (eg, using Dynamic Adaptive Streaming over HTTP (DASH) or Real-Time Transport Protocol (RTP), etc.). A content source can be a publisher (eg, a movie studio, 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 appreciated that these techniques may be applied to any of a variety of other content and content sources.

Content may be received from a content source via a website. For example, a website may allow a user to select and specify content and associated metadata, such as a list of titles and actors, directors, or other associated artists. Other techniques may be used to receive content from a content source, such as using an application programming interface (API). In some examples, metadata may be retrieved from a metadata repository maintained by another data source, such as a content source or a third-party metadata repository. Thus, content can be delivered to a CDN, where content records associated with the content are created within the distributed ledger. A content record contains a content hash that can be generated using any of a variety of hashing algorithms. Exemplary hashing algorithms include Secure Hash Algorithm 2 (SHA-2) hashes (eg, SHA-256, SHA-512, etc.) or RIPE Message Digest (RIPEMD) hashes (eg, RIPEMD-160, RIPEMD-256, etc.) ), but is not limited thereto. The content hash may be generated based on the content itself rather than based on metadata alone or metadata combined with the content.

Content hashes can be stored within a distributed ledger, for example within blocks of a blockchain. In some examples, the content record further includes at least some of the metadata associated with the content. In other examples, metadata may be stored in a metadata repository or other data store and associated with a content hash. Metadata can be hashed in a similar way, and the metadata hash can be stored as part of the content record so that subsequent authentication of the metadata can be performed. The content record may further include subsequent authentication associated with when the content was received by the CDN, and associated content source information (eg, email address, billing address, company name, etc.).

One or more smart contracts associated with the content may be created. For example, a CDN and a content source may be parties to a smart contract, in which case the CDN is rewarded for delivering the content and the content source is rewarded for playing the content. In other examples, a smart contract may be entered into between a CDN or content source and one or more other parties, such as musicians, heroines, and directors, such that these parties may receive royalty payments. let it be In some examples, smart contracts are used where the CDN is the only party to the contract, allowing the CDN to maintain analytics within the distributed ledger based on the occurrence of triggers.

A smart contract may be part of a distributed ledger where content hashes are stored, or in other examples, a different distributed ledger. For example, different distributed ledgers can be used for different parties (eg, different distributed ledgers 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, allowing ledger gateways to be used to synchronize transactions between the content source ledger and the CDN ledger, and provide indications for triggers, among other examples. .

It will be appreciated that a party to a smart contract need not be an actual user of the distributed ledger, but may otherwise act as a placeholder. For example, a royalty smart contract may be used to create an account of royalty payments associated with content, and such an account may be provided to a content source or other party to ultimately pay royalties. Thus, the smart contracts and distributed ledger techniques described herein may not result in actual value being exchanged, but may instead enable accounting techniques related to content distributed by CDNs.

A trigger can be a content transfer (e.g. sending to a client device or between an origin and an edge node, streaming or download activity, etc.) or content playback (e.g. playing/pausing content, fast-forward/ It can be any of a variety of events, such as events related to going back, ending playback early, etc.). Once a trigger is identified, the content hash associated with that trigger is used to identify and execute the associated smart contract. Although exemplary distributed ledger and smart contract techniques are described herein, it will be appreciated that any of a variety of other techniques may be used to create and execute smart contracts associated with content distributed by a CDN. For example, the content need not be used, and the identifier associated with the smart contract may instead be associated with the content itself.

Distributed ledgers can be processed to create within them payment accounts belonging to the parties to the smart contract. This processing may be performed periodically (eg monthly, semi-annually, etc.) and an indication of the account may be provided to the content source or other party. For example, a content source may receive such an indication and process royalty payments accordingly. As another example, a content source may receive this indication and process payment to the CDN for the CDN service provided to deliver the content.

Distributed ledgers can also be used to perform authentication related to content. For example, the consumer may want to authenticate the source of the content, or, in other examples, certain metadata associated with the content (e.g., that the heroine/heroine depicted in the content actually participated in the creation of the content). ) may be desired. Thus, content can be hashed (eg, at a consumer's client device, a CDN's node, etc.) and a content hash associated with that content can be identified within the distributed ledger. The content hash can be used to identify metadata associated with the content, thereby enabling a user to view the content source associated with the content and the associated metadata.

As mentioned above, the content from the content source may be of lower quality or may be in a different format than may be distributed by the CDN. Thus, AI-based transcoding techniques can be used to improve or change content. In examples, a set of transcoding models can be used to perform upscaling or other video enhancement techniques. A set of transcoding models may have been trained according to different content types. For example, different transcoding models may exist for action content, sports content, moving content, reality content, advertising content, and black and white content. The transcoding model includes content metadata (e.g., genres that can represent specific content types, male/female characters, etc.), video analytics (e.g. bitrate, frame complexity, lightness/darkness, etc.) , source content resolution, target content resolution, motion vector, year of manufacture, format or codec type, and/or selection from a set of models according to various criteria including, but not limited to, feedback received from consumers or other users. do.

In examples, multiple transcoding models are compared to determine which transcoding model to apply. For example, object detection (e.g., inanimate objects, moving characters, male/female characters, etc.) can be performed so that the model processing results from multiple transcoding models determine how well the detected objects are transcribed. can be compared based at least in part on whether they have been coded. This comparison may be automatic (eg, detecting transcoding artifacts, comparing a reference frame to a transcoded frame, etc.) and/or manual (eg, multiple transcodes for the user to select). providing coded frames, encouraging user feedback related to encoding quality after or during playback, etc.). For example, a source frame may be downscaled such that the downscaled source frame is upscaled using multiple transcoding models to produce multiple transcoded frames. Transcoded frames can be compared to the original source frames to identify errors and quality loss, so that the transcoding model showing the highest quality (e.g., lowest error, lowest quality loss, etc.) is selected for transcoding the content. make it possible

In examples, multiple transcoding models are used to transcode a single piece of content, in which case one model may be used for one sub-portion of content, while another model may be used for another sub-portion. can be used For example, sports broadcasts may be processed using a sports transcoding model, an advertisement transcoding model, and a “talking heads” or commentary transcoding model. As mentioned above, different transcoding models may be more suitable for different content types. Transcoding model performance can be evaluated periodically during transcoding so that the transcoding model can be changed according to the model performance for a given subpart. In some instances the content resolution may change (eg between a sports segment of a broadcast and a commercial within it), which may signal that model performance should be re-evaluated. In other examples, object detection techniques 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 re-evaluated. In some examples, the transcoding model applied to transcode the content is frame-by-frame or at any other granularity level (eg, every keyframe or intraframe, after a predetermined number of frames, etc.) Therefore, it may be re-evaluated. Additionally, different transcoding models may be applied to intra-frames, predicted-frames, and/or bi-directional-frames. Accordingly, it will be appreciated that a variety of techniques may be used to determine when to switch from one transcoding model to another to transcode content. Similarly, these techniques do not need to be performed concurrently with transcoding, but as a pre-processing operation to create a transcoding "recipe" that specifies which transcoding model should be used to transcode which sub-portion of content. may be performed.

It will be appreciated that similar techniques may be applied to audio, eg pure-audio content, or audio that is part of video content. Similar to the video techniques described above, multiple audio transcoding models can be evaluated to determine which audio transcoding model should be applied. Such evaluation may include identifying audio artifacts (eg, artifacts falling within human hearing range), resulting bitrate, errors and/or loss of quality of the transcoded audio. In examples, evaluating which audio transcoding model to apply occurs concurrently with the video transcoding model evaluation discussed above. Thus, an event that causes a re-evaluation of the video transcoding model to occur may similarly cause a re-evaluation of the audio transcoding model. Similarly, an event that causes a re-evaluation of the audio transcoding model to occur may cause a re-evaluation of the video transcoding model to occur. In other cases, audio and video transcoding models are re-evaluated separately from each other. A video transcoding model can be associated with an audio transcoding model so 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 delivery using distributed ledger and AI-based transcoding technology are performed. As shown, system 100 includes content source 102, gateway node 104, gateway node 106, regional node 108, client device 110, and network 112. Content source 102 , gateway node 104 , gateway node 106 , regional node 108 , and client device 110 are illustrated as communicating over network 112 . Network 112 may include, among other things, a local area network, a wide area network, one or more cellular networks, and/or the Internet. Nodes 104, 106, and 108 may include 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, these similar aspects may not necessarily have to be described again in detail for each node.

Content source 102 sends content to CDN 140 (e.g., using a client application 138 on client device 110) for delivery to consumers (e.g., using a gateway node as illustrated by the dashed lined box). (including 104 and 106), and local node 108). For example, a computing device associated with content source 102 is a website (e.g., node 104, 106, or 108) hosted by CDN 140 to provide content according to aspects described herein. ) can be used to access Any of a variety of other techniques may be used to transmit content from content source 102 to CDN 140 . In other examples, certain elements of the exemplary CDN described with respect to system 100 may be provided by third parties and/or the functionality described herein with respect to certain elements may be distributed according to any of a variety of other techniques. It will be understood that it can be.

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

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

Gateway node 104 may transmit content to local node 108 . Gateway nodes 104 and 106 distribute content to local nodes so that content received from content source 102 and provided to regional nodes 108 via gateway node 104 may subsequently be distributed by gateway node 106. It can be distributed from (108). Accordingly, CDN 140 may have a hierarchical or hub-and-spoke architecture, in which certain nodes (eg, nodes 104 and 106) are connected to other nodes (eg, nodes 104 and 106). eg, managed by the local node 108. While an example CDN structure is described herein, it will be appreciated that nodes may be configured in any of a variety of other structures in other examples.

A consumer uses a client application 138 on a client device 110 to access content from CDN 140 (eg, which may be provided to CDN 140 by content source 102 ). Client application 138 may be a web browser or application developed or provided by content source 102 , among various examples. Thus, client device 110 communicates with one or more of nodes 104, 106, and 108 and accesses content. In some examples, client device 110 initially communicates with content source 102 (eg, to access a list of content that may be provided through a website), and then client device 110 may be directed to CDN 140 to access a selected piece of content provided by CDN node 104 , 106 , and/or 108 . When content from content source 102 is transmitted within CDN 140 and/or provided to client device 110, one or more triggers may occur. For example, a consumer can cause a playback trigger to occur via a client application 138 by requesting content from the CDN 140 . Correspondingly, the distributed ledger engine identifies this trigger and executes the associated smart contract based at least in part on the hash of the associated content. For example, distributed ledger engine 120, 126, or 132 may perform this aspect. Executing a smart contract can result in an update to the distributed ledger associated with the corresponding trigger. As another example, a trigger causes a smart contract associated with sending and storing content to be executed (e.g., by distributed ledger engine 132 or 126) so that the content is transferred from local node 108's data store 130 to the gateway. may occur when transmitted to node 106.

In examples, the distributed ledger is processed to determine payments belonging to the parties to the smart contract therein (eg, content source 102, CDN 140, artist, etc.). For example, the distributed ledger engine 132 of the regional node 108 may perform this processing periodically (eg monthly, semiannually, etc.) and display the content source 102 and/or one or more may be provided to other parties. For example, content source 102 may receive such an indication and subsequently process a royalty payment accordingly. As another example, content source 102 may receive this indication and process a payment belonging to CDN 140 for the CDN service associated with delivering the content. In some examples, distributed ledger engine 132 provides a website, API, or method for accessing such aggregated payment information, managing smart contracts, and/or fulfilling money transfers. It will be appreciated that gateway nodes 104 and 106 may perform similar aspects in other examples. As another example, gateway nodes 104 and 106 may be managed by regional node 108 such that regional node 108 performs the aforementioned processing techniques on behalf of gateway nodes 104 and 106 .

In examples, content authentication is requested. For example, an authentication request is received from the client device 110 or, as another example, the content is authenticated as a result of creating an account on the distributed ledger. As another example, the consumer may want to authenticate the source of the content, or, in other examples, certain metadata associated with the content (e.g., that the heroine/heroine depicted in the content actually participated in the creation of the content). ) may be desired. Accordingly, a hash of the content is generated (eg, at client device 110 at node 104, 106 or 108, etc.) and compared to the content record in the distributed ledger. These aspects may be performed by distributed ledger engines 120 , 126 , and/or 132 . If the generated content hash matches the content record's stored content hash, the content is successfully authenticated. The content hash can be used to identify metadata associated with the content, thereby enabling a user to view the content source associated with the content and the associated metadata.

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

In other examples, node 104, 106, or 108 uses content processor 122, 128, or 136, respectively, to generate AI in response to a request for content (eg, from client device 110). - Original content is distributed to the nodes of CDN 140 to perform the based transcoding technique. For example, this request may include requested format information indicating the requested resolution, number of audio channels, bit rate, and/or color depth, among other examples. Accordingly, the requested format information may relate to requested video format information and/or requested audio format information. Additionally, distributing original content within CDN 140 and performing transcoding at nodes that process requests for such content may reduce the bandwidth associated with transmitting content within CDN 140 .

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

Local node 108 is illustrated as further including a model manager 134 . In examples, the transcoding models used by content processors 122 , 128 , and 136 are managed by model manager 134 . For example, content processor 122 may retrain or update a transcoding model used to transcode content based on implicit and/or explicit user feedback. Accordingly, these models can be provided to or retrieved by the model manager 134 , which can then distribute the updated transcoding model to other content processors in the CDN 140 . Thus, a transcoding model can be shared between nodes 104, 106, and 108. Similarly, model manager 134 may enable sharing of transcoding recipes among 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 certain piece of content, the model manager 134 may use the gateway node 106 Retrieves or accesses the corresponding transcoding recipe from, and shares the transcoding recipe with the content processors 122 and 136. Thus, the transcoded versions produced by nodes 104, 106, and 108 may be similar as a result of using the same or similar transcoding recipes. It will be appreciated that other techniques may be used to synchronize transcoding models and recipes. For example, a centralized data repository may be used.

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

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

The smart contract processor 154 of the distributed ledger engine 150 creates a smart contract associated with the content. As noted above, a smart contract may be created between a CDN, a content source, and/or any of a variety of parties including, but not limited to, musicians, heroines, and directors among other artists. can Smart contract processor 154 may associate the created smart contract with a content hash (eg, which may have been generated by hash generator 152). The smart contract processor 154 may store the smart contract within the same distributed ledger as the content record is stored, or in other examples the smart contract may be a different distributed ledger. For example, different distributed ledgers can be used for different parties (eg, different distributed ledgers 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 create smart contracts between distinct users, or in other instances, the parties to the smart contract need not be actual users and may instead act as placeholders. there is. For example, a royalty smart contract may be used to create a record of royalty payments, and such an account may be provided to a content source or other party to ultimately have royalties paid. As another example, the CDN is the sole party to the contract, so the CDN can maintain analytics information through the distributed ledger based on the occurrence of triggers.

The trigger processor 156 processes triggers and executes associated smart contracts. As mentioned above, a trigger can be a content transfer (e.g. transmission to a client device or between an origin and an edge node, streaming or download activity, etc.) or content playback (e.g. play/pause content). , fast-forward/rewind, prematurely ending playback, etc.). For example, trigger processor 156 can poll to determine whether an event has occurred (eg, accessing log data, querying a data store for content, etc.) , or an indication (eg from a CDN node, from a client device, etc.). When trigger processor 156 identifies a trigger, the content hash associated with that trigger is used to identify and execute the associated smart contract (e.g., which may have been created by smart contract processor 154).

Content authenticator 158 authenticates the content compared to content hashes in the distributed ledger. For example, content authenticator 158 may receive an authentication request (eg, as a result of processing a transaction from a client device, such as client device 110 of FIG. 1A ). The authentication request may include an indication to generate a hash for the particular content or may include a hash (eg, which may be generated by the client device). In instances where a hash was not received as part of the request, hash generator 152 generates a hash of the content. The content authenticator 158 then compares either the received hash or the generated hash with the hash in the distributed ledger to authenticate the content. As noted above, additional authentication may be performed in relation to content sources associated with content and/or metadata.

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

A model selector 182 selects a transcoding model for performing AI-based transcoding. For example, the model selector 182 selects a transcoding model, content metadata (eg, genre that can represent a particular content type, male/female characters, etc.), video analysis (eg, bit rate, frame complexity, contrast, etc.), original content resolution, target content resolution, motion vector, year of manufacture, format or codec type, and/or feedback received from consumers or other users. So choose As described above, a set of transcoding models may have been trained according to different content types. For example, different models may exist for action content, sports content, animated content, reality content, advertising content, and black and white content.

In examples, model selector 182 compares multiple transcoding models to determine which transcoding model to apply. For example, object detector 184 can identify inanimate objects, moving characters, and hero/heroines among other objects within a given video frame. Object detector 184 may apply any number and/or variety of cognitive machine learning models. For example, each object recognition machine learning model may have been trained to recognize a particular subset of objects, or in other examples an object recognition machine learning model is trained according to a particular type of content. It will be appreciated that object detector 184 may apply a variety of other object detection techniques (eg, identifying edges within a frame, analyzing motion across a set of frames, etc.).

Model selector 182 then evaluates model processing results from multiple transcoding models using quality evaluator 188 to determine how well detected objects were transcoded by each transcoding model. can In examples, quality evaluator 188 performs this comparison programmatically (eg, by detecting transcoding artifacts, comparing a reference frame to a transcoded frame, etc.). For example, a source frame may be downscaled such that the downscaled source frame is upscaled using multiple transcoding models to produce multiple transcoded frames. Transcoded frames can be compared to the original source frames to identify errors and quality loss, so that the transcoding model showing the highest quality (e.g., lowest error, lowest quality loss, etc.) is selected for transcoding the content. make it possible In other examples, quality evaluator 188 requests or receives explicit/implicit user input, for example by generating a display of several transcoded frames for user selection.

Transcoding engine 186 transcodes content to produce transcoded content. Transcoding engine 186 uses the transcoding model selected by model selector 182 to perform transcoding. In examples, multiple transcoding models are used to transcode content, in which case one model may be used for one sub-portion of content, while another model may be used for another sub-portion. . Thus, the transcoding model performance can be evaluated periodically during transcoding (e.g., by the quality estimator 188), allowing the transcoding model to change according to the model performance for a given subpart (e.g., by quality estimator 188). eg, according to a selection made by model selector 182). In some examples, the content resolution can be changed (e.g., a sports segment of a broadcast within content) so that transcoding engine 186 can determine that model selector 182 should be used again to perform the model selection process. and between ads). In other examples, object detector 184 can be used to determine the content of a video frame or to identify when an object has disappeared, both of which can cause model selector 182 to re-evaluate transcoding model performance. . In some examples, transcoding engine 186 applies a different transcoding model to intraframes, predicted-frames, and/or bi-frames (each of which may be selected by model selector 182). As mentioned above, this technique need not be performed concurrently with the transcoding, so that instead the transcoding engine 186 has a transcode that specifies which transcoding model should be used to transcode which sub-portion of the content. Make use of coding recipes.

2A illustrates an overview of an example method 200 for adding content to a CDN in accordance with the distributed ledger techniques described herein. In examples, aspects of method 200 are performed by a node of a CDN, such as node 104, 106 or 108 of FIG. 1A. As another example, aspects of method 200 may be performed by a distributed ledger engine, such as distributed ledger engine 150 of FIG. 1B . The method 200 begins at operation 202 where a presentation of content is received. The presentation of content may be received from a content source, such as content source 102 of FIG. 1A. As another example, presentation of content may be performed by a user (eg, a user of a client device associated with the content source) selecting the content, and a title and associated meta, such as a list of protagonists, directors, or other associated artists. It can be received through the website of the CDN, allowing the data to be specified. In other examples, metadata is stored within the metadata repository, and the content representation includes a reference to the metadata within 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 from this content. In examples, the hash is generated by a hash generator, such as hash generator 152 of FIG. 1B. For example, a content hash may be generated based on the content itself rather than based on metadata alone or metadata combined with the content. In examples, the content hash is part of the content record. A content record may store any of a variety of other information, such as hashes associated with content metadata and/or the metadata itself.

At operation 206, a smart contract associated with the content is created. A smart contract may be created by a smart contract processor, such as smart contract processor 154 of FIG. 1B. A smart contract is created between a CDN, a content source to which an indication received at operation 202 is associated, and/or various parties, including but not limited to musicians, heroines/protagonists, and directors among other artists. It can be. The smart contract created in operation 206 may be associated with the content hash that was created in operation 204 . As noted above, a smart contract need not be between separate users, or in other examples, a party to a smart contract need not be an actual user and may instead act as a placeholder. A smart contract may be associated with any of a variety of triggers that cause the smart contract to be executed in accordance with aspects described herein. Although operations 206 and 208 are described as creating one smart contract, it will be appreciated that any number of smart contracts may be created.

Moving to operation 208, the content hash and smart contract are stored within the distributed ledger. In examples, the content record created in operation 204 and the one or more smart contracts created in operation 206 are stored within the same distributed ledger. As another example, smart contracts can be stored in a distributed ledger separate from content records. For example, different distributed ledgers can be used for different parties (eg, different distributed ledgers for each content source, using the same distributed ledger to track royalty payments to a particular artist, etc.). Flow ends at operation 208 .

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

In operation 224, content authentication is performed. Content authentication may be performed by a content authenticator, such as content authenticator 158 of FIG. 1B , which may perform aspects of method 240 described below in FIG. 2C . Content authentication may have been generated by generating a hash for the content to which the trigger is associated and generating this hash within the content record of the distributed ledger (e.g., operations 204 and 208 of method 200 of FIG. 2A). ) and comparisons may be included. In another case, the content hash received in operation 222 is compared to the content hash in the distributed ledger to determine 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 payment may include content authentication, while a smart contract associated with analytics does not). may not be).

Flow proceeds to operation 226 where a smart contract associated with the large content is identified. In examples, the smart contract is stored on a distributed ledger, such as a content hash, allowing the smart contract to be identified therein. In other examples, a content hash is used to identify a smart contract in a different distributed ledger, or as another example, a content record can contain the same reference to a smart contract in a different distributed ledger. Accordingly, it will be appreciated that any of a variety of techniques may be used to identify a smart contract associated with a piece of content.

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

2C illustrates an overview of a method 240 for authenticating content according to the distributed ledger techniques described herein. In examples, aspects of method 220 are performed by a node of a CDN, such as node 104, 106 or 108 of FIG. 1A. As another example, aspects of method 240 may be performed by a distributed ledger engine, such as distributed ledger engine 150 of FIG. 1B . The method 240 begins at operation 242 where a request for content is received. In some examples, this request is received from a client device, such as client device 110 of FIG. 1A . In other examples, this request is received from a smart contract processor, such as smart contract processor 154 of FIG. 1B , which may perform aspects of operation 224 of FIG. 2B . The authentication of the request for the content is the content hash (eg, it may have been generated by the client device from which this request was received).

Flow may proceed to operation 244 where a hash of the content is generated. Operation 244 is illustrated using a dashed box to indicate that it may be omitted in some examples (eg, where the request for content authentication includes a content hash). Aspects of operation 244 may be performed by a hash generator, such as hash generator 152 of FIG. 1B. As noted above, the content hash may be generated based on the content itself rather than based on metadata alone or metadata combined with the content.

At operation 246, the stored hash is identified within the distributed ledger. According to aspects described herein, the stored hash may be part of a content record. In examples, a content record may be associated with content through a reference or other association. In some examples, authentication may not only be performed on content, but may also be performed on metadata. In this example, a stored metadata hash (eg, which may be part of a content record) 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.

In decision operation 248, it is determined whether the hashes match. For example, the content hash received in operation 242 or the content hash generated in operation 244 can be compared to the content hash identified in operation 246 . Exact matching is used in the examples. In other examples, a hash may have multiple subparts, where an exact match is used to compare the first subpart. One or more different sub-portions of the hash may be associated with a content resolution (eg, a different hash per sub-portion for HD, 4K, and/or 8K content) and/or a content source (eg, a streaming platform may may have a different hash subpart than the original content publisher)). As described above in operation 246, additional information, such as a metadata hash, may be evaluated as part of the determination. In some examples, the metadata itself can be stored as part of the content record, so that matching techniques can be used to evaluate aspects of the metadata. Accordingly, it will be appreciated that any of a variety of techniques may be used to determine if content hashes match, and the match does not have to be an exact match.

If decision operation 248 determines that the hashes do not match, flow proceeds along the “no” branch to operation 250 where an indication that the content is not authenticated is provided. In examples, this indication further includes why authentication failed (eg, hash subparts did not match, certain metadata was not authenticated, etc.). Flow ends at operation 250 .

However, if it is determined that the hashes match, flow proceeds along the “yes” branch to operation 252 where an indication that the content is authenticated is provided. In some instances, authentication may be an indication of authenticated information, more specific metadata (e.g., a non-perfect match indicates that the metadata is correct but incomplete, e.g., the first two letters of the heroine/heroine rather than the full name). may have a first and last name, have a typical release year rather than an exact date, etc.). Flow ends at operation 252 .

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

The method 300 begins at operation 302 where a presentation of content is received. An indication of the content may be received from a content source, such as content source 102 of FIG. 1A, when the content is being added to the CDN. In another example, an indication of content may be received from the client device upon initiating playback, such as may be received from client device 110 of FIG. 1A . In examples, the presentation of the content includes the requested resolution for the content and the location where the content was stored, among other requested format information (eg, 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 examples, such an indication need not include the requested format information, instead the requested format information may be determined based on device characteristics (e.g., screen size, number of speakers available, available bandwidth, etc.). can

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 of FIG. 1C. For example, a transcoding model can be used to perform content metadata (e.g. genres that can represent specific content types, male/female characters, etc.), video analytics (e.g. bitrate, frame complexity, lightness/ darkness), original content resolution, target content resolution, motion vector, year of manufacture, format or codec type, and/or feedback received from consumers or other users. It can be selected from a set of coding models. In some examples, operation 304 includes comparing multiple transcoding models to determine which transcoding model to apply. Method 350 of FIG. 3B illustrates one example of this aspect and is described in more detail below.

In operation 306, the content is transcoded using the transcoding model selected in operation 304. 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 content. For example, a first sub-portion may be transcoded according to the selected model in operation 304, after which transcoding may be paused, and flow returns to operation 304 to process a second sub-portion of content. You can choose a new transcoding model for . This aspect is illustrated by the arrow from action 306 to action 304 . Thus, transcoding model performance can be evaluated periodically by returning to operation 304, so that the transcoding model can be changed in dependence on model performance for a given sub-portion. In some examples, the content resolution may change, which may cause flow to return to operation 304 . In other examples, object detection techniques may be used to determine the contents of a video frame or to identify when an object has disappeared, both of which may cause flow to return to operation 304 . In some examples, the applied transcoding model may be re-evaluated on a frame-by-frame basis or according to any other level of granularity (eg, every keyframe or infraframe, after a predetermined number of frames, etc.). Further, while operations 304 and 306 are described as occurring sequentially, it will be understood that in other aspects sub-portion transcoding may occur in parallel, in which case different sub-portions may correspond to different transcoding models. Therefore, they are transcoded at the same time.

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

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

Flow proceeds to operation 308 where the quality of the transcoded content is evaluated. Operation 308 may be performed after content transcoding has 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 of FIG. 1C. For example, the determination may be made programmatically (eg, by detecting transcoding artifacts, comparing a reference frame to a transcoded frame, etc.) and/or upon explicit/implicit user input. may be based. User input can be historical user input based on previously transcoded content using the same or similar transcoding model, where the user indicates the perceived quality of the transcoded content (e.g., on a scale of 1 to 5). as a scale, as a binary indicator of whether the quality was good).

At decision operation 310, it is determined whether the quality satisfies a threshold. In examples, a predetermined error rate or quality loss is compared to the evaluation performed in operation 308 . In other examples, a predetermined score threshold is compared to the user input. It will be appreciated that any of a variety of different techniques and/or metrics and associated thresholds may be used to assess quality. If, at decision 310, it is determined that the quality threshold is not satisfied, flow passes to the "NO" branch and returns 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, allowing different transcoding models to include applying the same base transcoding model with varying settings and/or variables.

However, if it is determined that the transcoded content satisfies the quality threshold, flow instead branches “yes” to operation 312, where the transcoded content is provided. In examples, the transcoded content is provided to a client device for playback to a consumer. In other examples, the transcoded content is transmitted to a CDN's node 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 concludes at operation 312 .

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

The method 350 begins at operation 352 where a content frame is selected. In examples, the selected content frame is a frame to be transcoded by a content processor that may perform an aspect of method 300 of FIG. 3A. In other examples, the selected frame of content is a keyframe or frame determined to be representative of the content. For example, a frame may be selected as a result of having a relatively high degree of motion or detail, among other examples.

At operation 354, an object is detected within the selected content frame. Aspects of operation 354 may be performed by an object detector, such as object detector 184 of FIG. 1C. Action 354 may include identifying one or more inanimate objects, animated characters, and heroines/heroes, among other objects. The selected frames of content 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 have been trained to recognize a particular subset of objects, or in other examples an object recognition machine learning model is trained according to a particular type of content. It will be appreciated that any of a variety of other object detection techniques may be used (eg, identifying an edge within a frame, analyzing motion across a set of frames, etc.). In other examples, it is noted that operation 354 may be omitted such that operation 354 is illustrated using a dashed box so that the model selection technique of method 350 may not evaluate model performance specifically for the detected object. display

Flow proceeds to operation 356 where the resolution of the content frame is reduced. In examples, 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 (eg 1920x1080) content to 4K content (eg 3840x2160) results in a quadruple increase in pixel data. Accordingly, a 1080p HD source may be downscaled by a factor of 4 (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 dotted box to indicate that in other examples operation 356 may be omitted: For example, operation 356 indicates that the model processing result is not compared to the source content frame but to each other. can be omitted when compared to .

At operation 358, the content frame is processed using the set of transcoding models. In examples, processing the content frame may upscale the downscaled content frame (e.g., which may have been generated in operation 356) using the respective transcoding model to obtain the original image that was selected in operation 352. and providing a transcoded content frame having the same or similar resolution as the content frame. In some examples, transcoding the content frame includes utilizing the same base model but changing 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, a set of transcoding models may include content metadata (e.g., genre that can represent a particular content type, male/female characters, etc.), video analytics (e.g., bitrate, frame complexity, contrast ( lightness/darkness), original content resolution, target content resolution, motion vector, year of manufacture, format or codec type, and/or feedback received from consumers or other users. is therefore selected.

The flow proceeds to operation 360 where the set of transcoded content frames are scored according to quality. In examples, transcoded content frames may be scored programmatically (eg, by detecting transcoding artifacts, comparing reference frames to transcoded frames, etc.) and/or explicit/implied It can also be based on enemy user input. The transcoded content frames are scored individually, scored relative to each other, and/or based on the content frame that was selected in operation 352 . As noted above, user input may be received from a side-by-side display of transcoded frames, or it 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 of FIG. 1C .

In operation 362, an indication of the highest scoring transcoding model is provided. In examples, this indication is provided to a transcoding engine, such as transcoding engine 186 of content processor 180 of FIG. 1C. As an example, this indication may be used to transcode the content in operation 306 of method 300 of FIG. 3A. In examples, this indication includes the transcoded content frame so that the transcoding engine does not need to re-transcode the content frame that was selected in operation 352 . Although method 350 is described as selecting and processing one frame of content, it will be appreciated that in other examples multiple frames of content may be processed. For example, method 350 can determine a transcoding model for a set of frames, after which the model selection process can be performed again to identify the same or a different transcoding model. In this example, this indication includes an indication of the content sub-portion (eg, several frames according to timestamp, etc.) for which transcoding model should be used. Flow ends at operation 362 .

4 illustrates an example of a suitable operating environment 400 in which one or more of the embodiments of the invention may be implemented. This is only one example of a suitable operating environment and is not intended to suggest any limitation as to scope of use or functionality. Other well-known computing systems, environments, and/or configurations that may be suitable for use include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of these systems or devices, and the like.

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

Operating environment 400 may include at least some form of computer readable media. Computer readable media can be any available media that can be accessed by processing unit 402 or another device that includes such an operating environment. For example, computer readable media may include computer storage media and communication media. Exemplary computer storage media include any method or technology for storage of information, such as volatile and nonvolatile, removable and non-removable media embodied in computer readable instructions, data structures, program modules, or other data. may also include Computer storage media may include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that may be used to store 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” can mean a signal that has one or more of its characteristics set or changed in order to encode information within the signal. For example, communication media may include wired media such as a wired network or direct 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. A remote computer may be a personal computer, server, router, network PC, peer device, or other common network node, and typically includes many or all of the above and unmentioned elements. A logical connection may include any method supported by an available communication medium. Such networking environments are commonplace in offices, corporate computer networks, intranets, and the Internet.

The different aspects described herein may be employed using implementing and performing software, hardware, or a combination of software and hardware to implement and perform the systems and methods disclosed herein. Although specific devices are referred to throughout the specification as performing specific functions, one skilled in the art will recognize that such devices are provided for purposes of example and that other devices may be employed to perform the functionality disclosed herein without departing from the scope of the present invention. I will admit that you can.

As stated, several program modules and data files may be stored within system memory 404 . When executed in the processing unit 402, program modules (e.g., applications, input/output (I/O) management, and other utilities) may, for example, be illustrated in FIGS. 2A-2C and 3A-3B. A process including, but not limited to, one or more of the stages of the methods of operation described herein may be performed, such as a method described herein.

Moreover, examples of the present invention may be practiced within discrete electronic devices, packaged or integrated electronic chips containing logic gates, electrical circuits including circuits utilizing microprocessors, or in a single chip containing electronic devices or microprocessors. It can be. For example, an example of the present invention may be implemented via a system-on-chip (SOC) where each or many of the components illustrated in FIG. 4 may be integrated onto a single integrated circuit. Such SOC devices may include one or more processing units, graphics units, communication units, system virtualization units, and various application functionality, all of which are integrated (or "burned") on a chip substrate as a single integrated circuit. ). When operating through a SOC, the functionality described herein may be operated through application-specific logic integrated on a single integrated circuit (chip) along with other components of the operating environment 400 . Further, examples of the present invention may use other techniques capable of performing logical operations such as AND, OR, and NOT, including but not limited to, for example, mechanical techniques, optical techniques, hydrodynamic techniques, and quantum techniques. can be carried out. Further, examples of the invention may be practiced within a general purpose computer or within any other circuit or system.

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

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 fall within the scope and spirit of the present technology. Therefore, specific structures, acts, or media are disclosed only as exemplary embodiments. The scope of the technology is defined by the following claims and any equivalents therein.

Claims (40)

As a system,
at least one processor; and
a memory operably coupled to the at least one processor;
the memory stores instructions that, when executed by the at least one processor, cause the system to perform a set of operations;
The set of operations is
receiving, from a client device, a request for content of a content distribution network (CDN), the request for content including requested format information indicating a requested resolution different from a resolution of the content;
determining, from a set of transcoding models, a transcoding model to transcode the content;
transcoding at least a portion of the content, using the determined transcoding model, to generate transcoded content having the requested resolution; and
In response to the request for the content, providing transcoded content to the client device.
Including, system. According to claim 1,
The operation of determining the transcoding model,
selecting a content frame from the content;
downscaling the content frame;
the downscaled content frame;
processing using the first transcoding model to generate a first transcoded frame;
processing using 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.
including,
wherein the transcoding model is one of the first transcoding model or the second transcoding model. According to claim 2,
The operation of determining the transcoding model further includes recognizing an object of the content frame;
To determine the transcoding model, the first transcoded frame and the second transcoded frame are further evaluated based at least in part on a recognized subject matter of the content frame. According to claim 1,
The transcoding model is a first transcoding model,
at least a portion of the content is a first portion of the content;
The set of operations is
determining, from the set of transcoding models, a second transcoding model to transcode the content; and
and transcoding the second portion of the content using the determined transcoding model to further generate the transcoded content having the requested resolution. According to claim 1,
the client device is a first client device;
The request for the content is a first request for the content,
The set of operations is
storing the transcoded content in a data store;
receiving a second request for the content from the second client device; and
In response to the second request for the content, providing the transcoded content from the data store. According to claim 1,
The set of operations is
receiving a request for the transcoded content from a node of the CDN; and
The system further comprises providing the transcoded content to a node of the CDN. According to claim 1,
The system of claim 1, wherein the requested format information includes at least one of requested audio format information or requested video format information. A method for transcoding content using a transcoding recipe, comprising:
Receiving, from a node of a content delivery network (CDN), content and a transcoding recipe, the transcoding recipe comprising:
a first transcoding model for the first sub-portion of the content; and
A second transcoding model for the second sub-portion of the content
indicates -;
transcoding a first sub-portion of the content using the first transcoding model to produce a first transcoded sub-portion;
transcoding a second sub-portion of the content using the second transcoding model to produce a second transcoded sub-portion; and
providing transcoded content comprising the first transcoded sub-portion and the second transcoded sub-portion to a client device;
Including, content transcoding method. According to claim 8,
The method,
receiving a request for the content from the client device;
wherein the first subportion and the second subportion are transcoded based at least in part on receiving the request. 10. The method of claim 9, wherein:
The request for the content includes requested format information,
wherein the transcoding recipe is determined based at least in part on the requested format information. According to claim 8,
the client device is a first client device;
The method,
storing the transcoded content in a data store;
receiving a request for the content from the second client device; and
In response to the request for the content, providing the transcoded content from the data store.
Further comprising a content transcoding method. According to claim 8,
the first sub-portion of the content is a video track of the content;
wherein the second sub-portion of the content is an audio track of the content. According to claim 8,
The method,
receiving, from a node of the CDN, a request for the transcoded content; and
providing the transcoded content to a node of the CDN;
Further comprising a content transcoding method. A method for transcoding content from a content provider, comprising:
receiving, from a client device, a request for content of a content delivery network (CDN), the request for content including requested format information indicating a requested resolution different from a resolution of the content;
determining, from a set of transcoding models, a transcoding model to transcode the content;
transcoding at least a portion of the content, using the determined transcoding model, to produce transcoded content having the requested resolution; and
In response to the request for the content, providing the transcoded content to the client device.
Including, content transcoding method. 15. The method of claim 14,
Determining the transcoding model,
selecting a content frame from the content;
downscaling the content frame;
the downscaled content frame;
using the first transcoding model to generate a first transcoded frame;
processing using the 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.
including,
wherein the transcoding model is one of the first transcoding model or the second transcoding model. According to claim 15,
determining the transcoding model further comprises recognizing a subject matter of the content frame;
To determine the transcoding model, the first transcoded frame and the second transcoded frame are further evaluated based at least in part on a recognized subject matter of the content frame. 15. The method of claim 14,
The transcoding model is a first transcoding model,
at least a portion of the content is a first portion of the content;
The method,
determining, from a set of transcoding models, a second transcoding model to transcode 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.
Further comprising a content transcoding method. 15. The method of claim 14,
the client device is a first client device;
The request for the content is a first request for the content,
The method,
storing the transcoded content in a data store;
receiving, from the second client device, a second request for the content; and
In response to the second request for the content, providing the transcoded content from the data store.
Further comprising a content transcoding method. 15. The method of claim 14,
The method,
receiving, from a node of the CDN, a request for the transcoded content; and
providing the transcoded content to a node of the CDN;
Further comprising a content transcoding method. 15. The method of claim 14,
The requested format information includes at least one of requested audio format information or requested video format information. As a system,
at least one processor; and
a memory operably coupled to the at least one processor;
the memory stores instructions that, when executed by the at least one processor, cause the system to perform a set of operations;
The set of operations is
receiving, from a content source, a representation of content;
storing the 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, from a client device, a request for the content; and
In response to the request, providing at least a portion of the content from the data store.
Including, system. According to claim 21,
The set of operations is
generating a smart contract associated with the content, wherein the smart contract is associated with a trigger;
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 create a new record in the distributed ledger.
Further comprising a system. 23. The method of claim 22,
The set of operations is
processing the distributed ledger to identify at least the new record; and
based at least in part on the new record, generating an accounting indication associated with the content; and
providing the account representation to the content source;
Further comprising a system. According to claim 21,
the content hash is a first content hash;
The set of operations is
receiving, from the client device, an authentication request including a second content hash;
if the first content hash matches the second content hash, determining that the content is authenticated; and
In response to the authentication request, providing an indication that the content has been authenticated.
Further comprising a system. According to claim 21,
the display of the content further includes metadata associated with the content;
wherein the metadata is not used to generate the content hash. 26. The method of claim 25,
and at least a portion of the metadata is stored within the content record. 26. The method of claim 25,
and at least some of the metadata is stored in a metadata repository and associated with the content hash. A method for creating a smart contract for content in a content delivery network (CDN), comprising:
receiving, from a content source, a representation of content;
generating a smart contract associated with the content, wherein the smart contract is associated with a trigger;
Storing the smart contract in a distributed ledger;
receiving, from a client device, a request for the content;
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 create a new record in the distributed ledger; and
In response to the request, providing at least a portion of the content.
Including, a smart contract creation method. 29. The method of claim 28,
The method,
processing the distributed ledger to identify at least the new record; and
based at least in part on the new record, generating an account representation associated with the content; and
providing the account representation to the content source;
Further comprising, a smart contract creation method. 29. The method of claim 28,
The method,
generating a content hash based on the content;
storing the content hash as a content record in the distributed ledger;
Further comprising, a smart contract creation method. 31. The method of claim 30,
the content hash is a first content hash;
The method,
receiving, from the client device, an authentication request including a second content hash;
if the first content hash matches the second content hash, determining that the content is authenticated; and
In response to the authentication request, providing an indication that the content has been authenticated.
Further comprising, a smart contract creation method. 31. The method of claim 30,
the display of the content further includes metadata associated with the content;
wherein the metadata is not used to generate the content hash. 29. The method of claim 28,
wherein the content is a sub-portion of streaming content from the content source. A method for adding content to a content delivery network (CDN), comprising:
receiving a representation of content from a content source;
storing the 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, from a client device, a request for the content; and
In response to the request, providing at least a portion of the content from the data store.
Including, how to add content. 35. The method of claim 34,
The method,
generating a smart contract associated with the content, wherein the smart contract is associated with a trigger;
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 create a new record in the distributed ledger.
Further comprising, how to add content. 36. The method of claim 35,
The method,
processing the distributed ledger to identify at least the new record; and
based at least in part on the new record, generating an account representation associated with the content; and
providing the account representation to the content source;
Further comprising, how to add content. 35. The method of claim 34,
the content hash is a first content hash;
The method,
receiving, from the client device, an authentication request including a second content hash;
if the first content hash matches the second content hash, determining that the content is authenticated; and
providing an indication that the content has been authenticated in response to the authentication request;
Further comprising, how to add content. 35. The method of claim 34,
the display of the content further includes metadata associated with the content;
wherein the metadata is not used to generate the content hash. 39. The method of claim 38,
wherein at least a portion of the metadata is stored within the content record. 39. 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.

Images