Computer-implemented method, storage system and computer-readable storage medium

Abstract

A computer-implemented method, storage system, and non-transitory computer-readable storage medium are provided. The computer-implemented method includes receiving, by a storage system, a media file and at least one associated interstitial file; storing the at least one associated interstitial file to at least a high-accessibility type of storage; transcoding the at least one associated interstitial file into at least one transcoded file based at least in part on one or more settings specific to transcoding; storing the at least one transcoded file to the high-accessibility type of storage; and moving the at least one associated interstitial file to a reduced-accessibility type of storage after completion of the transcoding, the reduced-accessibility type of storage being operationally less expensive than the high-accessibility type of storage.

Description

[0001] This application is a divisional application of the invention patent application filed on September 13, 2017, with application number "201780056380.2" and title "Media Storage". The international filing date of the parent application is September 13, 2017, with international application number PCT / US2017 / 051385 and priority date of September 14, 2016. Technical Field

[0002] This application relates to the field of computer technology, and more particularly to a computer-implemented method, storage system, and computer-readable storage medium for managing asset storage. Background Technology

[0003] Users are increasingly acquiring content digitally, often downloading or streaming it from remote services. Content is typically uploaded in high-quality formats and then transcoded into various other formats suitable for replay on a wide range of devices. In some storage systems, storing both high-quality and transcoded versions can be quite expensive, and it can be difficult to correlate the various versions and enable customers to manage their diverse assets. Summary of the Invention

[0004] One aspect of this application provides a computer-implemented method comprising: receiving a media file and at least one associated mezzanine file by a storage system; storing the at least one associated mezzanine file at least in a high accessibility type of storage; transcoding the at least one associated mezzanine file into at least one transcoded file based at least in part on one or more transcoding-specific settings; storing the at least one transcoded file in the high accessibility type of storage; and after the transcoding is completed, moving the at least one associated mezzanine file to a reduced accessibility type of storage, the reduced accessibility type of storage being less operationally costly compared to the high accessibility type of storage.

[0005] Another aspect of this application provides a storage system comprising: at least one processor; a first type of storage; a second type of storage having lower accessibility than the first type of storage; and a memory including instructions that, when executed by the at least one processor, cause the storage system to perform the following operations: receiving a media file and at least one associated mezzanine file; storing the at least one associated mezzanine file at least in the first type of storage; transcoding the at least one associated mezzanine file into at least one transcoded file based at least in part on one or more transcoding-specific settings; storing the at least one transcoded file in the first type of storage; and, after the transcoding is completed, moving the at least one associated mezzanine file to the second type of storage, which is less costly to operate compared to the first type of storage.

[0006] Another aspect of this application provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores instructions that, when executed by at least one processor of a computing device, cause the computing device to perform the following operations: receiving a media file and at least one associated mezzanine file by a storage system; storing the at least one associated mezzanine file at least in a first type of storage; transcoding the at least one associated mezzanine file into at least one transcoded file based at least in part on one or more transcoding-specific settings; storing the at least one transcoded file in the first type of storage; and, after completing the transcoding, moving the at least one associated mezzanine file to a second type of storage, the second type of storage being less expensive to operate than the first type of storage. Attached Figure Description

[0007] Various embodiments according to this disclosure will be described with reference to the accompanying drawings, in which:

[0008] Figure 1 An exemplary environment in which various implementation schemes can be implemented is shown.

[0009] Figure 2 An exemplary subsystem for managing media file transcoding is shown, which can be utilized according to various implementation schemes.

[0010] Figure 3 An exemplary subsystem for managing content to a fast and archived storage location is shown, which can be utilized according to various implementation schemes.

[0011] Figure 4 An exemplary system for managing asset storage is shown, which can be utilized according to various implementation schemes.

[0012] Figure 5 Another exemplary system for managing asset storage is shown, which can be utilized according to various implementation schemes.

[0013] Figure 6 An exemplary process for enabling uploaded assets to be stored by a storage service, which can be utilized according to various implementation schemes, is shown.

[0014] Figure 7 An exemplary process for imposing a lifecycle on assets stored by a storage service is shown, which can be utilized according to various implementation schemes.

[0015] Figure 8 Exemplary components of a computing device are shown that can be used to implement various aspects of various implementation schemes. Detailed Implementation

[0016] Various implementation schemes will be described below. For illustrative purposes, specific configurations and details are set forth to provide a thorough understanding of the implementation schemes. However, it will be apparent to those skilled in the art that the implementation schemes can be practiced without the specific details. Furthermore, well-known features may be omitted or simplified to avoid obscuring the described implementation schemes.

[0017] The methods described and suggested in this document involve storing large files, such as high-quality multimedia files, in a storage environment. Customers or other users of the storage system can upload media or other such content to the storage system. As part of the upload process, the storage system can extract media metadata describing the media file being uploaded. The file can be a related file uploaded as part of a media asset. As part of the upload process, or as a separate process, the customer can specify one or more lifecycle policies to be applied to the media asset storage. Components such as a rules engine can ensure the management of one or more policies and their application to the media asset storage. Such a rules engine can also allow for the use of simple media processing workflows. For example, a workflow can be specified that uploads a high-resolution video file or mezzanine file, automatically transcodes it into one or more specified output formats, and shortly thereafter causes the mezzanine file to be archived to a lower-cost storage. Filename hashing methods can be used to ensure that fragments and files of an asset are stored in a relatively random and uniform distribution across partitions of the storage system. As part of the lifecycle process, high-quality media files can be moved to a cheaper storage after a defined event occurs (such as transcoding the asset into one or more related transcoded files).

[0018] As will be apparent to those skilled in the art from the teachings and suggestions contained herein, various other such functions may also be used within the scope of various implementations.

[0019] Figure 1 An exemplary environment 100 is shown, illustrating aspects of various implementation schemes. In this example, a user can utilize a client device 102 to submit requests to a resource provider environment 106 across at least one network 104. The client device may include any suitable electronic device operable to send and receive requests, messages, or other such information over a suitable network and to transmit information back to the user of the device. Examples of such client devices include personal computers, tablets, smartphones, laptops, and the like. Network 104 may include any suitable network, including intranets, the Internet, cellular networks, local area networks (LANs), or any other such networks or combinations, and may enable communication over the network via wired and / or wireless connections. Resource provider environment 106 may include any suitable components for receiving requests and returning information or performing actions in response to those requests. As an example, the provider environment may include a web server and / or application server for receiving and processing requests and then returning data, web pages, video, audio, or other such content or information in response to those requests.

[0020] In various implementations, the provider environment may include a variety of types of electronic resources that can be used by multiple users for a variety of different purposes. In at least some implementations, all or a portion of a given resource or group of resources may be allocated to a specific user or assigned to a specific task for at least a defined period of time. Sharing these multi-tenant resources from the provider environment is commonly referred to as resource sharing, web services, or “cloud computing” and other such terms, depending on the specific environment and / or implementation. In this example, the provider environment includes multiple electronic resources 114 of one or more types. These types may include, for example, application servers capable of operating to process instructions provided by users, or database servers capable of operating to process data stored in one or more data storage areas 116 in response to user requests. As is known, for such purposes, users may also retain at least a portion of the data storage in a given data storage area. Methods for enabling users to retain various resources and resource instances are well known in the art, and therefore a detailed description of the entire process and an explanation of all possible components will not be discussed in detail herein.

[0021] In at least some implementations, a user wishing to utilize a portion of resource 114 may submit a request, which is received by interface layer 108 of resource provider environment 106. The interface layer may include an application programming interface (API) or other exposed interfaces that enable users to submit requests to the provider environment. In this example, interface layer 108 may also include other components, such as at least one web server, routing components, load balancers, etc. When a request to provide resources is received by interface layer 108, the requested information may be directed to resource manager 110 or other such systems, services, or components configured to manage user accounts and information, resource provisioning and usage, and other such aspects. Resource manager 110 receiving the request may perform tasks such as authenticating the identity of the user submitting the request and determining whether the user has an existing account with the resource provider, wherein account data may be stored in at least one data store 112 within the provider environment. Users may provide any of a variety of types of credentials to authenticate their identity to the provider. These credentials may include, for example, username and password pairs, biometric data, digital signatures, or other such information.

[0022] The resource provider can verify this information by comparing it with information stored for the user. If the user has an account with appropriate permissions, status, etc., the resource manager can determine whether there are sufficient resources available to satisfy the user's request, and if so, can supply resources or otherwise grant access to the corresponding portion of those resources for the user's use in the amount specified in the request. This amount may include, for example, the capacity to process a single request or perform a single task, a specified time period, or a recurring / reproducible time period, and other such values. If the user does not have a valid account with the provider, the user account is not allowed to access the type of resource specified in the request, or another such reason prevents the user from obtaining access to such resources, then communications may be sent to the user to enable the user to create or modify an account or change the resources specified in the request, and other such options.

[0023] Once a user is authenticated, an account is verified, and resources are allocated, the user can utilize the allocated resources to obtain specified capabilities, data transfer volumes, time periods, or other such values. In at least some embodiments, the user may provide a session token or other such credentials along with subsequent requests to enable those requests to be processed on the user session. The user may receive a resource identifier, a specific address, or other such information that enables the client device 102 to communicate with the allocated resources without having to communicate with the resource manager 110, at least until changes occur such as changes to aspects related to the user account, when the user is no longer permitted to access the resource, or another such change.

[0024] In this example, Resource Manager 110 (or another such system or service) may also serve as a virtual layer for hardware and software components that handle control functions beyond management actions, such as provisioning, scaling, copying, etc. Resource Manager may utilize dedicated APIs in Interface Layer 108, each of which may be provided to receive requests for at least one specific action to be performed relative to the data environment, such as provisioning, scaling, cloning, or hibernating an instance. Upon receiving a request from one of the APIs, the Web service portion of the Interface Layer may parse or otherwise analyze the request to determine the steps or actions required to act on or process the call. For example, a Web service call may be received that includes a request to create a data repository.

[0025] In at least one implementation, the interface layer 108 includes a scalable set of client-facing servers that provide various APIs and return appropriate responses based on API specifications. The interface layer may also include at least one API service layer, in one implementation, consisting of stateless replicated servers that handle externally-facing client APIs. The interface layer may be responsible for web service front-end features such as authenticating clients based on credentials, authorizing clients, restricting client requests to the API server, validating user input, and marshalling or demarcating requests and responses. The API layer may also be responsible for reading database configuration data from / writing database configuration data to the management data store in response to API calls. In many implementations, the web service layer and / or the API service layer will be the only externally visible components, or the only components visible to and accessible to clients of the control service. As is known in the art, the servers for the web service layer can be stateless and horizontally scalable. Similar to persistent data stores, API servers may be distributed, for example, across multiple data centers in a region, making the servers resilient to the failure of a single data center.

[0026] Figure 2 It shows what can be used in, such as, about Figure 1 Exemplary system 200, implementing various implementation schemes in the electronic environment under discussion. Figure 2In the system, client computing device 202 may submit a request for content across at least one network 204 for it to be received by content provider environment 206. As described above, in at least some embodiments, the request may include a request for content to be displayed on client computing device 202, and in many cases will include video or other media content transcoded for presentation on client computing device 202. The one or more networks may include any suitable network, such as the Internet, local area network (LAN), cellular network, Ethernet, or any other such wired and / or wireless network. Content provider environment 206 may include any suitable resources for providing content from resource providers, including various servers, data storage areas, and other such components known or used for providing content from a network (or from the “cloud”). As described elsewhere herein, client computing device 202 may be any suitable computing or processing device, including desktop or laptop computers, smartphones, tablets, wearable computers (i.e., smartwatches, glasses, or touchscreens), set-top boxes, or other such systems or devices. Upon receiving a request or call, interface layer 208 can determine the type of call or request and cause the information to be forwarded to the appropriate component or subsystem. For example, a request for content can be forwarded to media server 210, while a request specifying encoding parameters can be forwarded to transcoding manager 216, and other such options. These calls or requests can also originate from third parties, although third-party provider 506 may also provide at least some of the media content to be stored in a media repository and transcoded for display on client computing device 202, as discussed herein.

[0027] In this example, the call received by content provider environment 206 may be received by the interface layer 208 of said environment. As is known for the network environment, the interface layer may include components such as interfaces (e.g., APIs), load balancers, request and / or data routers, etc. If the request is for content, such as a request for a video data stream to be provided to client computing device 202, the request information may be directed to one or more media servers 210, which may obtain content from media data storage areas or other such repositories to send the content back to the computing device across one or more networks. In some embodiments, the request information may also be compared with user data in user data storage area 214 or other such locations to determine, for example, whether the user has access rights to the content, and potentially to determine the format or version to which the user has access rights.

[0028] In at least some implementations, requests from an operator, administrator, client computing device 202, third-party provider 224, or another such source may include requests specifying one or more sets of encoding parameters to be used with the media file. Therefore, information about the encoding parameters may be provided to transcoder 216 or other such components or services capable of receiving the information through an appropriate interface (i.e., API or console) and causing configuration file 218 and parameter data 220 to be stored in an appropriate repository, as discussed elsewhere herein. When a request for a video file is received, transcoder 216 may use the configuration file and parameter data to determine appropriate encoding information and may pass this encoding information to one or more transcoders 222, which may obtain the media file and transcode it according to the transcoding information, and the media file may then be provided to the client device by media server 210 or other such components.

[0029] In some implementations, the transcoding subsystem includes one or more transcoders, a set of bitstreams (or video signals), and a content delivery network. One or more transcoders may include both encoders and packetizers, which can be implemented via an origin server. Packers may receive signals (e.g., feeds), such as video signals or live streams. Live stream feeds may include live video content (e.g., sporting events, concerts, pay-per-view events, etc.), pre-recorded content (e.g., television programs, movies, time-lapse events, sports highlights, etc.), and / or advertising content (e.g., commercials), etc. Packers may receive one or more input signals (e.g., inputs) and generate one or more bitstreams. Bitstreams may be delivered to a content delivery network (CDN) by the encoder / packer. Bitstreams may represent various encoded / packed versions of the signal feed, which may be encoded according to encoding parameters from transcoding manager 216. For example, a bitstream may be a high-resolution and / or high-bitrate version of the signal feed. In some implementations, different bitstreams may provide alternative audio (e.g., different languages) and / or closed captions. The number and / or type of bitstreams may vary depending on the configuration file or other data.

[0030] Each bitstream may include multiple content segments, which may represent a portion of the bitstream. Each content segment file may represent a replay time segment of the program feed (e.g., a 10-second segment file may contain 10 seconds of video and / or audio). For example, when played back sequentially, content segments may generate content for the corresponding bitstream. In another example, content segments may be stored locally on the end-user device (e.g., buffered), and the end-user device may decode content segments for replay when enough are available. Content segments may be adaptive video content. Content segments allow for efficient and reliable delivery of the bitstream. For example, requesting individual content segments may reduce the likelihood of a download failure on a client device. In another example, storing content segments across a CDN may reduce the amount of storage required at each node of the CDN. The CDN itself may include a network of computers (e.g., servers). Each of the computers in the CDN may serve as a node, and the CDN may store and / or deliver bitstreams over a wide area network (e.g., the Internet).

[0031] An encoder / packet can be an active bitrate video HTTP server. The encoder / packet can receive signals (e.g., requests) and send signals (e.g., responses). A signal request can represent a data request (e.g., an HTTP request) from one of the client devices that is forwarded by the CDN to the origin server. For example, a signal request can be an HTTP request from the origin server to send digital data to one of the client devices. A signal response can represent a data response from the origin server that is to be forwarded by the CDN to one of the client devices. For example, the origin server can send a signal response (e.g., data such as content fragments) as a network packet to one of the client devices based on the HTTP protocol. The type, implementation, and / or number of responses and / or requests can vary depending on the design criteria of a particular implementation. The origin server can include a manifest file or a list of available content fragments. For example, a manifest file can include metadata and / or URLs pointing to content fragments and / or other data. The manifest file can be used by the client device to request content fragments. The format of the manifest file can vary depending on the design criteria of a particular implementation. The manifest file and / or content fragments can have corresponding Time-to-Live (TTL) values. TTL values ​​(or properties) can be used to ensure that certain objects in the network are refreshed. For example, objects in the network can be cached (e.g., throughout the CDN). The TTL value can represent the amount of time, number of requests, and / or hop count before an object is refreshed (e.g., requested / updated from the origin server). The TTL values ​​for manifest files and / or content fragments can be set by the operator and / or at the origin server. In common CDN implementations, various types of content can remain stored on the CDN until the TTL value expires (e.g., content invalidation can take a long time). Typically, the TTL value of the manifest file is less than the TTL value of the content fragment. A lower TTL value for the manifest file allows the manifest file to be refreshed more frequently / more often than the content fragment (e.g., to update pointers to content fragments). A relatively higher TTL value for the content fragment allows the content fragment to remain cached for a longer period (e.g., to reduce the number of requests made to the origin server and / or reduce the load on the origin server). The implementation and / or values ​​for the TTL values ​​of manifest files and / or content fragments can vary depending on the design criteria of the specific implementation.

[0032] Origin servers can be configured to perform content invalidation. For example, one or more content segments can be invalidated. Content invalidation can prevent and / or stop content delivery to client devices. To initiate content invalidation, an operator can send an invalidation signal (e.g., operator-initiated content invalidation) to the origin server. The origin server can invalidate content segments by updating (or manipulating) the manifest file. For example, the manifest file can be updated to no longer point to the content segment. Because the TTL value of the manifest file is relatively low, the manifest file can be refreshed throughout the CDN. For example, a client device can request a manifest file, and when the TTL value of the cached manifest in various nodes of the CDN expires, the updated manifest file (e.g., an invalidated manifest) can be distributed to client devices throughout the CDN.

[0033] In one example, a user can initiate changes to the video stream. In another example, a quality of service (QoS) test can be implemented. For example, if the video stream represented by content segments is of such poor quality that advertisers and / or broadcasters would be dissatisfied, the content segments can be quickly rearranged (e.g., by providing alternative content) and / or removed. For example, if a content segment represents a poor-quality advertisement (e.g., failing the QoS test), an alternative advertisement can be displayed by invalidating the content segment. If a content segment fails the QoS test, it can be automatically invalidated.

[0034] An exemplary manifest file may include various data, such as file headers, metadata, and / or pointers / links. The data may be human-readable or encoded using encoding formats, encrypted formats, and / or computer-readable (e.g., binary) formats. The format of the data in the manifest file may vary depending on the design criteria of a particular implementation. The file header provides an indicator that identifies the manifest file as a specific type of file. For example, the file header may be used by a source server, cache node, and / or any other computing device to identify the manifest file as a specific type of file (e.g., a pointer file, a manifest file, etc.). Metadata may indicate the type of file to be served when a specified link is followed. For example, metadata may indicate that the link represents a video stream, the bandwidth required to replay a content segment, the codec implemented for the content segment, the resolution of the content segment (e.g., in pixels), and / or any other relevant data. The type of data available in the metadata may vary depending on the design criteria of a particular implementation. Pointers may point to various types of stored data. The stored data may be content segments. For example, a pointer may be an HTTP URL link. In some implementations, pointers may be implemented as RTMP links and / or FTP links. The format of the pointers may vary depending on the design criteria of a particular implementation. A pointer to the manifest file can point to a corresponding content segment. In some implementations, the content segment can be implemented as a transport stream (e.g., .ts) file. For example, the content segment may include MPEG-2 data. In some implementations, the manifest file may be embedded within the bitstream. The type of invalidation and / or recovery can vary depending on the design criteria of the particular implementation. The type of invalidation can be based on invalid information (e.g., instructions) provided in the invalidation signal input. For example, the signal input could be a content invalidation signal initiated by an operator.

[0035] As mentioned above, many traditional shared resource environments struggle to manage various aspects of media storage, such as media lifecycle management and processing. For example, various media providers may want to keep the original, high-quality media files on storage, but for high-resolution video and other content, the file size can be very large. The size of this file (often called a mezzanine file) can make storage very expensive for the media provider. In many cases, media providers prefer to use mezzanine files for tasks such as transcoding to a highly compressed and lower-quality output format, thus eliminating the need to store the mezzanine file on expensive storage. This could include, for example, archiving large mezzanine files to cheaper types of storage. Traditional systems do not provide a convenient and automated way to provide and manage this process, including managing the data and files associated with the media content.

[0036] Therefore, methods according to various implementations can provide improved upload and management methods that are particularly beneficial to media and other content providers. In at least some implementations, the system's clients or other users can upload media or other such content to the storage system. As part of the upload process, the storage system can extract media metadata and parse any additional media-specific industry-standard formats of the metadata, which describe the media file being uploaded. This metadata can be stored in a dedicated metadata repository or other such accessible location. As part of the upload process, or as part of a separate process, the client can specify one or more lifecycle policies to be applied to the storage of media files. Components such as a rules engine can then ensure the management of one or more policies and their application to media asset storage. As an example, the client can specify that any media file larger than 100 gigabytes in size will be stored in archive storage after initial transcoding to at least one compressed format. Such a rules engine can also allow for the use of simple media processing workflows. For example, a workflow can be specified that uploads a high-resolution video file or mezzanine file, automatically transcodes it to one or more specified output formats, and then, shortly thereafter, causes the mezzanine file to be archived to a lower-cost storage.

[0037] Figure 3An overview of an exemplary system 300, according to various implementations, for managing the uploading of such media files is shown. In this example, a client may utilize a client interface 302 provided by an application executing on a client device to upload a high-quality media file via at least one network 304 for reception by an interface 310 of an interface layer 308 of a resource provider environment 306. Information about the uploaded file may be directed to a media management service 312, which may include a rules engine and various other components discussed and suggested elsewhere herein. The media service 312 may analyze the upload to locate and extract appropriate metadata, which may be stored in a metadata repository 314 or other such location within the resource provider environment 306. The media management service may also determine any rules or policies that should be applied to the processing and / or storage of the uploaded media file from the upload or other instructions previously provided by the client. In this example, applicable rules may cause the media content to be stored in a fast storage medium 316, such as high-speed, high-availability solid-state storage. The media file may then be processed according to the applicable rules and / or policies. In this example, media files can be processed by media management service 312 while being stored in fast storage 316, and then moved to archive storage 318 after processing is complete. Archive storage (sometimes also called cold storage) can be cheaper, slower, or less accessible storage, such as storage containing a simple disk drive configuration or other such storage. In some implementations, lower storage tiers will have lower accessibility, particularly where data only requires evidence of its existence and a possible reporting location. This can be moved to very inexpensive storage, including off-site tape vassals and other such storage. Metadata stored for media files in metadata repository 314 can be managed by media management service 312 to be applied to media files when they are stored in fast storage 316 or archive storage. Information regarding the storage of media files to different types of storage can be provided to billing system 320, which is shown here as part of a resource provider environment, but in other implementations may be outside of said environment. The billing system may store information in the billing data repository 322 or other such locations, so as to appropriately bill customers for the amount of time spent storing files in the fast storage 316 and the amount of time spent storing files in the archive storage 318 during the billing period, as well as other related costs.

[0038] In some implementations, a storage system agent may be used to receive upload requests from various clients or other such entities. This may include, for example, a dedicated address, interface, or Uniform Resource Locator (URL) that a client can use to upload media files. Upload requests received at a provided address can be processed using the methods discussed and suggested herein, while requests received at a regular upload address can be processed using regular or other methods. Additional interfaces may be provided for other tasks, such as querying metadata or requesting additional transcoding, and other such options. Media files received at a dedicated address or interface can be processed using a metadata extractor 418, such as... Figure 4 As shown in the exemplary system 400, a storage manager 412, receiving media files from a client interface 402 via a dedicated interface 410 of the interface layer, can instruct the media file to be processed by a metadata extractor 418. This can cause basic information to be extracted from the media file, which may include information such as format, bitrate, file size, etc. Another interface 410 of the interface layer 408 allows the client to specify additional metadata attributes, which, in at least some embodiments, may include custom attributes. Attributes may include key-value pairs or other such formats. Industry-standard metadata formats (e.g., XML) may also be parsed to determine relevant attributes to be stored for the media file.

[0039] Once the metadata extractor 418 extracts the metadata and stores it in an appropriate location, such as the metadata repository 422, the metadata manager can use the metadata to manage media files. The ability to utilize the metadata manager 420 in conjunction with the storage manager 412, as discussed herein, also enables the management of media assets. As used herein, a media “asset” refers to a logical collection of files that includes not only the source media files but may also include additional files that may involve additional text, metadata, and other supplementary content. Media management methods associated with one or more related interfaces 410 can introduce the concept of assets as a first-class object type. When a client uploads an asset, the asset may include all related files of the media content. Files may be stored separately in the fast storage 414 and / or archive storage 416 within the resource provider environment 406, but files can be considered logical groups. The storage manager 412 can track relationships between files to logically group them together. As discussed elsewhere herein, in at least some embodiments, new primitives can be generated for assets, which enable users to run queries or perform tasks relative to the primitives. Primitives can be hierarchical to reflect assets and sub-assets, where workflow tasks can be performed against one or more appropriate levels of the hierarchy. Furthermore, clients can utilize APIs or other such interfaces to perform queries against asset primitives and associated metadata. Lifecycle management performed by a rules engine or other such systems or services can also manage lifecycle tasks against asset primitives to ensure that tasks are executed and applied to all relevant documents for the asset.

[0040] An important aspect of managing assets by storage manager 412 involves managing the names of files associated with said assets. These names may include not only file names but also other names that can be used to manage these assets. For example, if a video asset is part of a series of assets, it would be desirable to extract and store the metadata to allow for queries or other operations that can identify or process all assets associated with said series. Other such names or identifiers may include title sections, seasons, episodes, episode titles, and other such information. Metadata may be stored as a source of truth in a table, which, in at least some embodiments, will also not be in the archive storage for at least some assets in which one or more versions of content are not stored. New interfaces (e.g., APIs) and methods may enable clients to query assets based at least in part on any of these names or identifiers. In some embodiments, clients uploading media assets will have the option to assign a name to said asset that can be applied to all associated files.

[0041] In addition to asset-level metadata, the storage manager can also manage time-code-specific metadata. For certain types of content, such as sports events, there may be events that occur at specific times in the replay timeline. These could include, for example, a pitching in a baseball game or a ball-handling in a soccer game, and other such points. Therefore, content providers may want to use timecode information to index their media content and enable clients or other users to query the content for specific types of information. As an example, a producer might want to pull up a highlight reel showing the final three batters who went out after three strikes. In this example, the video content could have pitch-by-pitch metadata associated with the timecodes in the video itself, allowing for quick identification and retrieval of those segments of the video.

[0042] Storage manager 412 may include, or work in conjunction with, a rules engine, which may be part of rules manager 424 or another such system or service. As previously described, rules manager 424 manages various rules and policies to be applied or enforced against various media objects. Rules manager 424 may also manage various workflows indicated by those rules or policies and may be part of the media lifecycle. This may include, for example, the ability to specify metadata-based queries on received and stored media assets. In some implementations, the client may specify metadata-based queries, which may be in plain language or query language, and other such options. As an example, the client may specify that all those files be archived to archive storage 416 24 hours after the mezzanine files are uploaded and received by the storage manager or another such system or service. The client may also specify that all assets with metadata related to a specific holiday (such as New Year's Day) be moved from archive storage 416 to fast storage 414 30 days before a specific holiday. As part of the lifecycle or other aspects, the rules engine may also have the ability to initiate transcoding jobs or other such tasks. In some implementations, this may be achieved using background scheduling processes and other such options. Relevant APIs or other such interfaces allow clients to specify rules and enable or disable them. The backend process can then periodically scan the index, running proactive queries to identify matching assets and take one or more appropriate actions as specified by the client. In some systems, clients can specify XML files for transcoding jobs, indicating information such as input and output formats, appropriate names, and other such information. These files can also be used for transcoding jobs triggered by the rule manager 424, which instructs how files associated with assets should be processed. If the transcoding engine is provided as a Software as a Service rather than a dedicated system in the environment, the service can be invoked to perform the transcoding of media files. Otherwise, a set of servers or other such systems can be maintained to host one or more transcoding engines applicable to the media assets.

[0043] In some implementations, the client-facing interface 410 may be a Web Services Representational State Transfer (REST) ​​API. This interface may allow the specification of various types of information presented herein, which may involve the specification of storage proxies, metadata retrieval and management, asset support, and rules / policies / workflows, among other such options. One or more software development kits (SDKs) may also be provided to clients in various languages, providing the tools needed for clients to communicate with the appropriate client interface. The API can then communicate with various subsystems discussed herein, including name hashing services, metadata services, and rule management services, etc.

[0044] As described above, in many cases, customers will want to store high-quality mezzanine files in Fast Storage 414, at least until the files are transcoded into one or more suitable formats. In this example, Storage Manager 412 may work with Transcoding Manager 428 to perform appropriate transcoding jobs. This can be achieved using transcoded data stored in Transcoding Repository 430 or other such locations. Once generated, various files in the specified formats can be stored in Fast Storage 414 and / or any other suitable location for access by authorized users or entities. The high-quality mezzanine files can then be moved from Fast Storage 414 to Archive Storage 416 according to rules or policies specified by the customer and managed by Rule Manager 424. Storage Manager 412 may also work with Metadata Manager 420 to ensure that appropriate metadata and other information about the asset are associated with the transcoded files in Fast Storage and the mezzanine files in Archive Storage.

[0045] In this example, the metadata manager 420 or storage manager 412 may also be responsible for filename management, including hashing functionality for various filenames or other such functions. However, it should be understood that a separate filename manager may also be used in various implementations. Furthermore, some storage systems can generate and manage their own filenames and hashes, making separate components or processes unnecessary. In this example, the Fast Storage service can distribute files across multiple different partitions. Multiple media files may have similar names, especially when each file is associated with a program or series. For a file named TestFile1, the source file may be transcoded into, for example, HLS segments, where an hour-long video file may be broken down into multiple two-second segments. Using conventional methods, the segments might be named TestFile1-001, TestFile1-002, TestFile1-003, etc. If a hash is generated using the beginning of the filename to determine the appropriate partition for that file, as in some conventional systems, then all filenames will hash to the same value, so they will all be stored on the same partition on the disk.

[0046] Therefore, new hash codes are generated according to various implementation methods, such as the SHA-256 hash (a cryptographically secure hash for filenames). The advantage of hash algorithms such as the SHA-256 generator is that the algorithm examines the entire filename, ensuring that each filename hashes to a different hash code. These different hash codes thus allow the distribution of those files across disk storage to be relatively random and uniform. By avoiding hotspots to ensure sufficiently high throughput, this contributes to the performance of the storage system.

[0047] Figure 5Another exemplary system 500 that can be utilized according to various implementations is illustrated. In this example, a client can use a client system 502 and / or a software development kit 506 to make invocations across at least one network 504 to a resource provider environment 508. As previously described, such an environment may include multiple APIs or other interfaces that enable the client to communicate with the resources of the environment. One of these APIs corresponds to a storage agent service 516, which the client can use to upload files or assets to be stored in storage 520 of the resource provider environment 508. The client may perform the upload as a multipart upload or as a compressed file (e.g., a .zip file), which may contain associated files or components of the asset. In this example, a mapping component 518 may generate hash code filenames using an appropriate hash algorithm and may store the mapping between hash codes and original filenames. The mapping component 518 may also associate hash codes with components or files of assets stored at various locations throughout the environment, and the mapping itself may be stored in a database table or other suitable location. In at least some embodiments, agent service 516 may cause individual components of an asset to be stored in an appropriate storage unit 520, such as a fast storage unit. In some embodiments, storage unit 520 may be provided as part of a storage service with various available storage events 532, enabling the publication of messages based on those events to trigger various scripts to be executed in the environment. For example, an event corresponding to the upload of a file to the storage service may trigger a script to run, which places a job in an ingest queue 524. The job may indicate that the file needs to be analyzed and ingested by an appropriate ingestor 528 in the environment. In at least some embodiments, ingestion jobs may be retrieved from ingest queue 524 and processed in parallel at a large scale. Ingestor 528 may perform tasks on the file, such as extracting metadata from media files or parsing and processing metadata from metadata XML files, and other such options. Once the metadata is obtained, it may be stored in a metadata repository 526 or another such location associated with the media file in storage unit 520.

[0048] Data integrity checker 530 can also be used to verify the integrity of uploaded data. In at least some environments, storage events are not guaranteed and may be lossy. Therefore, uploading an asset may not trigger an upload event, thus preventing scripts from being triggered. The data integrity checker can run in the background to periodically query appropriate table indexes to determine if there are media files whose metadata has not yet been identified and processed. This helps prevent event loss. However, it should be noted that in at least some implementations, clients can make calls to the proxy service 516 and provide their own metadata, or they can provide the metadata directly to the appropriate metadata API 522. That API also allows clients or other users to query metadata stored in the metadata repository 526. As examples, these may include queries such as those for displaying any asset with an HLS transcoded version in storage, providing information on the largest asset, or displaying all assets associated with a specific title.

[0049] Figure 5 The system 500 shown also includes a rules API 510, which allows customers to define lifecycle rules that can be executed by the rules engine 512, either directly or through SDK 506. The rules engine can execute queries defined in the rules table against the metadata API 522 to identify any matching assets. For any matching asset, the rules engine 512 can create a job message that will enter the lifecycle queue 514. Jobs can be processed from the queue to perform tasks, such as moving files between different storage classes or running video transcoding jobs, and other such options. Customers can submit or define lifecycle policies for a variety of different reasons. For example, a customer can specify that any version of an asset accessed less than once a day should be moved to a less frequently accessed storage. Access frequency can be determined by analyzing event logs or aggregating statistical usage data, and other such options.

[0050] The advantages of storing assets in this environment are: ads can be processed to match any format provided by transcoding the assets. Audio can then be matched, for example, to the audio of a live stream in which ads are inserted. Furthermore, the video quality of the ads can be adjusted to match the video quality of the current stream, and the switching between ads and the live stream can be virtually seamless and imperceptible to the viewer.

[0051] Figure 6An exemplary process 600 for enabling assets to be stored by a storage service, which can be utilized according to various embodiments, is shown. It should be understood that, unless explicitly stated otherwise, within the scope of various embodiments, additional, fewer, or alternative steps may exist for any process herein, performed in a similar or alternative order or in parallel. In this example, the media asset file is received 602 to a storage proxy service, such as by receiving it via a proxy URL or other such address or interface. As mentioned above, media assets may include a primary high-quality media file, as well as other files that may contain text, metadata, or other relevant information. Metadata 604 can be extracted from the media file using any of the various processes discussed and suggested herein, whether from the primary media file or from associated files. The metadata can then be stored 606 to a metadata repository and associated with the media asset.

[0052] The filename of the asset (608) can be determined, which may be based on a filename provided with the asset, provided by the customer, or otherwise generated. As described above, a hash algorithm can be used to generate a unique hash code (610) based on the filename, including any variations for different files or fragments. In at least some embodiments, these filenames can be mapped back to the original asset via a mapping table. The media fragments of the asset (612) can then be stored in high-accessibility storage or other high-performance storage. As described above, the unique hash code helps to distribute these fragments relatively randomly and evenly across various storage partitions. It can be determined (614) whether any rules, policies, or lifecycles related to the event exist, which may have been provided with the asset or otherwise identified by the customer or another such entity. In some embodiments, the applicable rules or lifecycles can be determined based on one or more values ​​of metadata associated with the asset. If applicable rules or lifecycles exist, the rule or lifecycle data (616) can be stored and associated with the asset. The asset (618) can then be made accessible through the storage service.

[0053] Figure 7 An exemplary process 700 for managing the lifecycle of media asset storage performed by a storage service is illustrated, which can be utilized according to various implementation schemes. In this example, methods such as those relative to... Figure 6The described process involves storing high-quality media files of an asset in high-accessibility storage. As part of the asset's lifecycle or in response to a customer request, and other such options, a set of transcoding formats for the asset is determined (704). Encoding formats may include, for example, NTSC, PAL, SECAM, MP3, WAV, and UTF. Using the high-quality media files stored in high-accessibility storage, a transcoding engine for accessible media files can be used to perform a transcoding task (706). The transcoded files can then be stored (708) in high-accessibility storage for authorized users to access. As part of the transcoding process, any rules, policies, or lifecycle applicable to the asset are determined (710). Once transcoding is complete (or in response to another appropriate action, event, or event), a determination (712) is made regarding whether the media files should be moved out of high-accessibility (and expensive) storage. If so, the high-quality media files can be moved (714) to lower-accessibility storage, which reduces the cost of storing the high-quality media files. Transcoded files can be stored in high-accessibility storage, making them accessible to users, and because these files are highly compressed, the storage cost is lower than that of high-quality files. Metadata and any rules, policies, or lifecycle data can be associated with both high-quality files in low-accessibility storage and transcoded files in high-accessibility storage, and customers can use one or more appropriate system APIs to query or download assets or metadata.

[0054] Figure 8A set of basic components of an exemplary computing device 800 that can be used to implement various aspects of various embodiments is shown. In this example, the device includes at least one processor 802 for executing instructions that can be stored in a memory device or element 804. As will be apparent to those skilled in the art, the device may include many types of memory, data storage, or computer-readable media (such as a first data storage for program instructions to be executed by at least one processor 802), identical or separate storage for images or data, removable memory for sharing information with other devices, and any number of communication methods for sharing with other devices. The device may include at least one type of display element 806, such as a touchscreen, e-ink, organic light-emitting diode (OLED), or liquid crystal display (LCD), but devices such as servers may transmit information by other means, such as optical and data transmission systems. The device will typically include one or more networking components 808, such as ports, network interface cards, or wireless transceivers that enable communication over at least one network. The device may include at least one input device 810 capable of receiving regular input from a user. This conventional input may include, for example, buttons, touchpads, touchscreens, steering wheels, joysticks, keyboards, mice, trackballs, keypads, or any other such devices or elements that a user can use to input commands to the device. In some embodiments, these I / O devices may even be connected wirelessly via infrared, Bluetooth, or other links. However, in some embodiments, such devices may not include any buttons at all and may be controlled solely through a combination of visual and audio commands, allowing the user to control the device without physical contact.

[0055] As discussed, different methods can be implemented in various environments depending on the described implementation scheme. It will be understood that although a web-based environment is used in several examples presented herein for illustrative purposes, various environments may be used to implement various implementation schemes where appropriate. The system includes electronic client devices, which may include any suitable device capable of operating to send and receive requests, messages, or information over a suitable network and to transmit information back to a user of the device. Examples of such client devices include personal computers, mobile phones, handheld messaging devices, laptop computers, set-top boxes, personal data assistants, e-book readers, and the like. The network may include any suitable network, including intranets, the Internet, cellular networks, local area networks, or any other such network or combinations thereof. The components used in such a system may depend at least in part on the type of network and / or environment chosen. Protocols and components used for communication over such a network are well known and will not be discussed in detail herein. Communication over the network may be achieved via wired or wireless connections and combinations thereof. In this example, the network includes the Internet because the environment includes web servers for receiving requests and providing content in response; however, for other networks, alternative devices for serving similar purposes may be used, as will be apparent to those skilled in the art.

[0056] An exemplary environment includes at least one application server and one data storage area. It should be understood that several application servers, layers, or other elements, processes, or components may exist that can be chained together or otherwise configured to interact and perform tasks such as retrieving data from a suitable data storage area. As used herein, the term "data storage area" refers to any apparatus or combination of apparatuses capable of storing, accessing, and retrieving data, including any combination of any standard, distributed, or clustered environment and any number of data servers, databases, data storage devices, and data storage media. The application server may include any suitable hardware and software designed to integrate with the data storage area as needed for various aspects of executing one or more applications on the client device and to handle most of the application's data access and business logic. The application server provides access control services in cooperation with the data storage area and is capable of generating content such as text, images, audio, and / or video to be delivered to the user; in this example, the content may be provided to the user by a web server in the form of HTML, XML, or another suitable structured language. All request and response processing and content delivery between the client device and the application server may be handled by the web server. It should be understood that web servers and application servers are not required and are merely exemplary components, as the structured code discussed herein can be executed on any suitable device or host as discussed elsewhere in this document.

[0057] Data storage areas may include several separate data tables, databases, or other data storage facilities and media for storing data related to a specific aspect. For example, the data storage areas shown include facilities for storing content (e.g., production data) and user information, which can be used to provide content to the production side. Data storage areas also shown include facilities for storing logs or session data. It should be understood that many other aspects may need to be stored in the data storage area, such as page image information and access permission information, which may be stored, as appropriate, in any of the facilities listed above or in other facilities within the data storage area. Data storage areas can be operated by their associated logic to receive instructions from application servers and, in response, obtain, update, or otherwise process data. In one example, a user may submit a search request for a certain type of item. In this case, the data storage area may access user information to verify the user's identity and may access catalog details to obtain information about items of that type. The information may then be returned to the user, for example, as a list of results on a web page, which the user can view through a browser on their device. Information about specific items of interest can be viewed in a dedicated page or window of the browser.

[0058] Each server will typically include an operating system that provides executable program instructions for the general administration and operation of the server, and each server will typically include a computer-readable medium storing the instructions, which, when executed by the server's processor, allow the server to perform its intended functions. Suitable implementations of the server's operating system and general functions are known or commercially available and readily implementable by those skilled in the art, particularly based on the disclosures herein.

[0059] In one embodiment, the environment is a distributed computing environment utilizing several computer systems and components interconnected via communication links, using one or more computer networks, or direct connections. However, those skilled in the art will understand that such a system can operate equally smoothly in systems with fewer or more components than those shown. Therefore, the description of the system herein should be considered illustrative in nature and does not limit the scope of this disclosure.

[0060] Various implementations can be further implemented in a wide range of operating environments, in some cases of which may include one or more user computers or computing devices that can be used to operate any of the multiple applications. User or client devices may include any of a variety of general-purpose personal computers, such as desktop or laptop computers running standard operating systems, and cellular, wireless, and handheld devices running mobile software and capable of supporting a variety of network connectivity and messaging protocols. Such systems may also include multiple workstations running a variety of commercially available operating systems and any other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and other devices capable of communicating over a network.

[0061] Most implementations utilize at least one network familiar to those skilled in the art, which uses any of a variety of commercially available protocols (such as TCP / IP, FTP, UPnP, NFS, and CIFS) to support communication. The network can be, for example, a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), the Internet, an intranet, an extranet, the public switched telephone network (PSTN), an infrared network, a wireless network, and any combination of the above.

[0062] In implementations utilizing a web server, the web server can run any of a variety of server or middleware applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. The server is also capable of executing programs or scripts in response to requests from user devices, such as by executing programs in any programming language (e.g.,...). One or more web applications written in one or more scripts or programs in C, C#, or C++, or any scripting language (such as Perl, Python, or TCL), or combinations thereof. The server may also include a database server, including but not limited to those that can access databases from... and Commercially acquired servers, as well as open-source servers (such as MySQL, Postgres, SQLite, MongoDB), and any other servers capable of storing, retrieving, and accessing structured or unstructured data. Database servers may include table-based servers, document-based servers, unstructured servers, relational servers, non-relational servers, or combinations of these and / or other database servers.

[0063] The environment may include various data storage areas as discussed above, as well as other memory and storage media. These may reside in a variety of locations, such as on storage media local to one or more computers (and / or residing within one or more computers), or on any or all computers remotely on a network. In a particular set of embodiments, information may reside in a storage area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing functions belonging to a computer, server, or other network device may be stored locally or remotely where appropriate. Where the system includes computerized devices, each such device may include hardware elements electrically coupled via a bus, including, for example, at least one central processing unit (CPU), at least one input device (e.g., mouse, keyboard, controller, touch-sensitive display element, or keypad), and at least one output device (e.g., display device, printer, or speaker). Such a system may also include one or more storage devices, such as disk drives, tape drives, optical storage devices, and solid-state storage devices (e.g., random access memory (RAM) or read-only memory (ROM)), as well as removable media devices, memory cards, flash memory cards, etc.

[0064] Such devices may also include computer-readable storage medium readers, communication devices (e.g., modems, network interface cards (wireless or wired), infrared communication devices), and working memory as described above. A computer-readable storage medium reader may be connected to or configured to receive computer-readable storage media, which represents remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information. The systems and various devices will also typically include multiple software applications, modules, services, or other elements residing within at least one working memory device, including operating systems and applications such as client applications or web browsers. It should be understood that alternative embodiments may have numerous variations from the embodiments described above. For example, custom hardware may also be used, and / or specific elements may be implemented in hardware, software (including portable software such as applets), or both. Furthermore, connections to other computing devices, such as network input / output devices, may be employed.

[0065] The foregoing can be better understood in accordance with the following terms:

[0066] 1. A computer-implemented method, comprising:

[0067] The interface for receiving assets, including video files, into the storage service.

[0068] Extract metadata from the asset and associate the metadata with the asset in the storage service;

[0069] The video file is stored in a first type of storage device of the storage service;

[0070] The video file is transcoded into one or more compressed files with the corresponding format;

[0071] Store the one or more compressed files into the first type of storage device of the storage service;

[0072] Determine the lifecycle corresponding to the asset;

[0073] As part of the lifecycle and after the transcoding, the video file is moved to a second type of storage, which has lower accessibility than the first type of storage.

[0074] Provide the one or more compressed files for download via one or more download interfaces of the storage service;

[0075] Query requests specifying values ​​for one or more metadata parameters are received by the metadata interface; and

[0076] Provide a response to the query request, the response providing information about the asset based at least in part on the values ​​of the one or more metadata parameters associated with the asset.

[0077] 2. The computer-implemented method as described in Clause 1, further comprising:

[0078] Determine the filename of the asset;

[0079] The video file is divided into a series of segments;

[0080] For each segment of the series, determine a variant of the filename; and

[0081] A unique hash code is generated for each segment of the series by using a hash algorithm that takes into account the overall characteristics of each variant.

[0082] 3. The computer-implemented method as described in Clause 1, further comprising:

[0083] Detecting events related to the asset through the storage service; and

[0084] The script corresponding to the event is executed, at least in part, based on the lifecycle associated with the asset.

[0085] 4. The computer-implemented method as described in Clause 1, further comprising:

[0086] The video file is indexed at least in part based on time code information extracted from the video file; and

[0087] Provide an interface that enables the asset to be queried at least in part based on the time code information.

[0088] 5. The computer-implemented method as described in Clause 1, wherein the cost per unit of storage of the second type of storage is lower than that of the first type of storage.

[0089] 6. A computer-implemented method, comprising:

[0090] The assets, including mezzanine files and one or more related files, are received into the storage system.

[0091] Extract metadata from the assets;

[0092] Associating the metadata with the mezzanine file and the one or more related files stored in the storage system;

[0093] Determine the workflow to be applied to the asset, the workflow being associated with the mezzanine file, the one or more related files, and any subsequently generated files associated with the asset in the storage system;

[0094] Detect events corresponding to the described workflow; and

[0095] This causes the execution of workflow tasks associated with the event relative to the mezzanine file, the one or more related files, and the corresponding files in the subsequently generated files.

[0096] 7. The computer-implemented method as described in Clause 6, further comprising:

[0097] Create at least one hierarchical primitive related to the mezzanine file and the one or more associated files for the asset; and

[0098] The workflow and the metadata are associated with the at least one hierarchical primitive, wherein the workflow and the metadata are automatically associated with the mezzanine file, the one or more related files, and the subsequently generated file, and wherein the actions of the workflow can be applied based on the at least one hierarchical primitive.

[0099] 8. The computer-implemented method as described in Clause 7, further comprising:

[0100] One or more tools are provided that enable a user to interact with the asset based on the at least one hierarchical primitive, wherein actions performed in response to user input via the one or more tools are performed at the asset level or sub-asset level of the hierarchical primitive.

[0101] 9. The computer-implemented method as described in Clause 6, wherein the workflow task is executed in response to a user's call to an application programming interface (API) or an action triggered by a rules engine that manages the workflow on behalf of the asset.

[0102] 10. The computer-implemented method as described in Clause 7, further comprising:

[0103] Determine at least one of the rules, policies, or lifecycles corresponding to the mezzanine file; and

[0104] The event triggers a movement of the mezzanine file to the second type of storage, which is specified as part of at least one of the rules, policies, or lifecycles.

[0105] 11. The computer-implemented method as described in Clause 6, further comprising:

[0106] Transcode the mezzanine file into one or more transcoded files with a specified format; and

[0107] The mezzanine file is moved to a second type of storage, which has lower accessibility than the first type of storage where the mezzanine file was originally stored. Metadata associated with the mezzanine file is stored in the second type of storage, and the one or more transcoded files are stored in the first type of storage.

[0108] 12. The computer-implemented method as described in Clause 6, further comprising:

[0109] Determine the filename of the media asset;

[0110] The mezzanine file is segmented into a series of fragments;

[0111] For each segment of the series, determine a variant of the filename; and

[0112] A unique hash code is generated for each segment of the series by using a hash algorithm that takes into account the overall characteristics of each variant.

[0113] 13. The computer-implemented method as described in Clause 6, further comprising:

[0114] The mezzanine file is indexed at least in part based on time code information extracted from it; and

[0115] An interface is provided that enables the mezzanine file to be queried at least in part based on the time code information.

[0116] 14. The computer-implemented method as described in Clause 6, further comprising:

[0117] The mezzanine file is received by a proxy service of the storage system, the proxy service having a dedicated address for receiving the mezzanine file.

[0118] 15. The computer-implemented method as described in Clause 6, wherein the metadata includes at least one of the title, format, bitrate, or file size of the mezzanine file.

[0119] 16. A storage system comprising:

[0120] At least one processor;

[0121] First type of storage;

[0122] A second type of storage, which has lower accessibility than the first type of storage; and

[0123] The memory includes instructions that, when executed by the at least one processor, cause the system to:

[0124] The assets, including mezzanine files and one or more related files, are received into the storage system.

[0125] Extract metadata from the assets;

[0126] Store at least the mezzanine files into the first type of storage in the storage system;

[0127] Associating the metadata with the mezzanine file and the one or more related files in the storage system;

[0128] Obtain a workflow to be applied to the asset, the workflow being associated with the mezzanine file, the one or more related files, and any subsequently generated files associated with the asset in the storage system;

[0129] Detect events corresponding to the described workflow; and

[0130] This causes the execution of workflow tasks associated with the event relative to the mezzanine file, the one or more related files, and the corresponding files in the subsequently generated files.

[0131] 17. The storage system as described in Clause 16, wherein the instructions, when executed, further cause the system to:

[0132] Create at least one hierarchical primitive related to the mezzanine file, the one or more related files, and the subsequently generated files for the asset; and

[0133] The workflow and the metadata are associated with the at least one hierarchical primitive, wherein the workflow and the metadata are automatically associated with the mezzanine file, the one or more related files, and the subsequently generated file, and the actions of the workflow can be applied based on the at least one hierarchical primitive.

[0134] 18. The storage system as described in Clause 16, wherein the instructions, when executed, further cause the system to:

[0135] Receive a set of advertisements to be displayed along with the asset;

[0136] This causes the advertisement to be modified to match at least one of the video quality or audio quality of the transcoded file generated using the mezzanine file; and

[0137] This causes the advertisement to be displayed during the replay of the transcoded file.

[0138] 19. The storage system as described in Clause 16, wherein the instructions, when executed, further cause the system to:

[0139] The mezzanine file is transcoded into one or more transcoded files with a specified format; and

[0140] The mezzanine file is moved to a second type of storage, which has lower accessibility than the first type of storage. Metadata associated with the mezzanine file is stored in the second type of storage, and the one or more transcoded files are stored in the first type of storage.

[0141] 20. The storage system as described in Clause 16, wherein the instructions, when executed, further cause the system to:

[0142] Determine the filename of the media asset;

[0143] The mezzanine file is segmented into a series of fragments;

[0144] For each segment of the series, determine a variant of the filename; and

[0145] A hash algorithm that takes into account the overall nature of each variant is used to generate a unique hash code for each segment of the series.

[0146] Storage media and other non-transitory computer-readable media used to contain code or code portions may include any suitable media known or used in the art, such as, but not limited to: volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data), including RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage devices, magnetic cartridges, magnetic tapes, disk storage devices or other magnetic storage devices, or any other media that can be used to store desired information and is accessible by system devices. Based on the disclosure and teachings provided herein, those skilled in the art will understand other ways and / or methods for implementing the various embodiments.

[0147] Therefore, this specification and accompanying drawings should be interpreted in an illustrative rather than restrictive sense. However, it will be apparent that various modifications and changes can be made without departing from the broader spirit and scope of the invention as set forth in the claims.

Claims

1. A computer-implemented method, the computer-implemented method comprising: The storage system receives media files and at least one associated high-resolution video file; The at least one associated high-resolution video file shall be stored in at least a high-accessibility type of storage. The at least one associated high-resolution video file is transcoded into at least one transcoded file, based at least in part on one or more transcoding-specific settings; Store the at least one transcoded file into the high-accessibility type of storage. as well as After the transcoding is completed, the at least one associated high-resolution video file is moved to a reduced accessibility type of storage, which is less costly to operate compared to the high accessibility type of storage.

2. The computer-implemented method according to claim 1, further comprising: Create at least one hierarchical primitive associated with the at least one associated high-resolution video file; The metadata extracted from the media file is associated with the at least one associated high-resolution video file; as well as The metadata is associated with the at least one hierarchical primitive, wherein the metadata is automatically associated with the at least one associated high-resolution video file and subsequently generated files, and wherein actions of a workflow to be applied to the media file can be applied based on the at least one hierarchical primitive.

3. The computer-implemented method according to claim 2, further comprising: At least one tool is provided for interacting with the media file based on the at least one hierarchical primitive, wherein actions performed in response to input made through the at least one tool are performed at the file level of the hierarchical primitive.

4. The computer-implemented method according to claim 1, wherein, The computer-implemented method further includes: performing the workflow on the media file in response to a call to an application programming interface or in response to an action triggered by a rules engine representing the media file management workflow.

5. The computer-implemented method according to claim 2, further comprising: Determine at least one of the rules, policies, or lifecycles corresponding to the at least one associated high-resolution video file; as well as The movement of the at least one associated high-resolution video file is triggered in response to the completion of the transcoding.

6. The computer-implemented method according to claim 1, further comprising: The metadata associated with the at least one associated high-resolution video file is stored in the storage of the high-accessibility type.

7. The computer-implemented method according to claim 1, further comprising: Determine the filename of the media file; The at least one associated high-resolution video file is segmented into a series of fragments; For each segment of the series, determine a variant of the filename; as well as A unique hash code is generated for each segment of the series by using a hash algorithm that takes into account the overall characteristics of each variant.

8. The computer-implemented method according to claim 1, further comprising: The at least one associated high-resolution video file is indexed at least in part based on time code information extracted from the at least one associated high-resolution video file; as well as An interface is provided that enables querying of the at least one associated high-resolution video file based at least in part on the time code information.

9. The computer-implemented method according to claim 1, further comprising: The at least one associated high-resolution video file is received by a proxy service of the storage system, the proxy service having a dedicated address for receiving the at least one associated high-resolution video file.

10. The computer-implemented method according to claim 2, wherein, The metadata includes at least one of the title, format, bitrate, or file size of the at least one associated high-resolution video file.

11. A storage system, the storage system comprising: At least one processor; First type of storage; The second type of storage has lower accessibility than the first type of storage; as well as The memory includes instructions that, when executed by the at least one processor, cause the memory system to perform the following operations: Receive media files and at least one associated high-resolution video file; The at least one associated high-resolution video file is stored in at least the first type of storage. The at least one associated high-resolution video file is transcoded into at least one transcoded file, based at least in part on one or more transcoding-specific settings; Store the at least one transcoded file into the first type of storage; as well as After the transcoding is completed, the at least one associated high-resolution video file is moved to the second type of storage, which is cheaper to operate than the first type of storage.

12. The storage system according to claim 11, wherein, When the instruction is executed, it further causes the system to perform the following operations: Create at least one hierarchical primitive associated with the at least one associated high-resolution video file; The metadata extracted from the media file is associated with the at least one associated high-resolution video file; as well as The metadata is associated with the at least one hierarchical primitive, wherein the metadata is automatically associated with the at least one associated high-resolution video file, and wherein actions of a workflow to be applied to the media file can be applied based on the at least one hierarchical primitive.

13. The storage system according to claim 11, wherein, When the instruction is executed, it further causes the system to perform the following operations: Receive a set of advertisements to be displayed along with the media file; The advertisement is modified to match at least one of the video quality or audio quality of the transcoded file generated using the at least one associated high-resolution video file; and The advertisement is displayed during playback of the transcoded file generated using the at least one associated high-resolution video file.

14. The storage system according to claim 11, wherein, When the instruction is executed, it further causes the system to perform the following operations: The second type of storage is used to store the metadata associated with the at least one associated high-resolution video file.

15. The storage system according to claim 11, wherein, When the instruction is executed, it further causes the system to perform the following operations: Determine the filename of the media file; The at least one associated high-resolution video file is segmented into a series of fragments; For each segment of the series, determine a variant of the filename; as well as A hash algorithm that takes into account the overall nature of each variant is used to generate a unique hash code for each segment of the series.

16. A non-transitory computer-readable storage medium, wherein, The non-transitory computer-readable storage medium stores instructions that, when executed by at least one processor of the computing device, cause the computing device to perform the following operations: The storage system receives media files and at least one associated high-resolution video file; The at least one associated high-resolution video file is stored in at least a first type of storage. The at least one associated high-resolution video file is transcoded into at least one transcoded file, based at least in part on one or more transcoding-specific settings; Store the at least one transcoded file into the first type of storage; as well as After the transcoding is completed, the at least one associated high-resolution video file is moved to a second type of storage, which is cheaper to operate than the first type of storage.

17. The non-transitory computer-readable storage medium according to claim 16, wherein, When executed by the at least one processor, the instructions further cause the computing device to perform the following operations: Create at least one hierarchical primitive associated with the at least one associated high-resolution video file; The metadata extracted from the media file is associated with the at least one associated high-resolution video file; as well as The metadata is associated with the at least one hierarchical primitive, wherein the metadata is automatically associated with the at least one associated high-resolution video file and subsequently generated files, and wherein actions of a workflow to be performed on the media file can be applied based on the at least one hierarchical primitive.

18. The non-transitory computer-readable storage medium according to claim 16, wherein, When executed by the at least one processor, the instructions further cause the computing device to perform the following operations: Receive a set of advertisements to be displayed along with the media file; The advertisement is modified to match at least one of the video quality or audio quality of the transcoded file generated using the at least one associated high-resolution video file; as well as The advertisement is displayed during playback of the transcoded file generated using the at least one associated high-resolution video file.

19. The non-transitory computer-readable storage medium according to claim 16, wherein, When executed by the at least one processor, the instructions further cause the computing device to perform the following operations: The second type of storage is used to store the metadata associated with the at least one associated high-resolution video file.

20. The non-transitory computer-readable storage medium according to claim 16, wherein, When executed by the at least one processor, the instructions further cause the computing device to perform the following operations: Determine the filename of the media file; The at least one associated high-resolution video file is segmented into a series of fragments; For each segment of the series, determine a variant of the filename; as well as A hash algorithm that takes into account the overall nature of each variant is used to generate a unique hash code for each segment of the series.

Images