DEPLOYING WORKFLOW TASKS WITH FIXED, PRESCRIBED PARAMETERS IN CLOUD-BASED MEDIA APPLICATIONS - Patent application

Abstract

The present disclosure generally relates to the development and deployment of media applications using NBMP systems. More specifically, the present disclosure describes a method and apparatus for instance-level configuration of functions used in NBMP workflows. An exemplary mechanism is provided for configuring different instances of the same function in various tasks in a media processing workflow with customized configurations and restrictions based on the format of the function's general configuration descriptor.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 332,614, filed April 19, 2022, which claims the benefit of priority to U.S. Non-Provisional Patent Application No. 18 / 310,810, filed April 17, 2023. Each of these prior patent applications is incorporated herein by reference in its entirety.

[0002] This disclosure relates generally to media streaming technologies using network-based media processing (NBMP). More specifically, this disclosure describes a method and apparatus for instance-level configuration of functionality used in NBMP workflows. [Background technology]

[0003] The discussion of the background art provided herein is intended to generally present the context for the present disclosure. The inventors' work is not admitted expressly or implicitly as prior art to the present disclosure to the extent that that work is described in this background section, along with aspects of the description that may not otherwise be admitted as prior art at the time of filing of this application.

[0004] Network and cloud platforms may be used to run various media applications. A network-based media processing (NBMP) system provides a platform for defining, instantiating, and executing workflows in a cloud-based environment. Such workflows can be executed individually, in parts, by task, or by groups of tasks. NBMP shows great potential for improving media processing efficiency, faster and less costly deployment of media services, and the ability to provide large-scale deployments by leveraging public, private, or hybrid cloud services. NBMP enables various multimedia service providers and network / cloud service providers to collaborate to offer customized immersive media services to customers. Summary of the Invention [Means for solving the problem]

[0005] The present disclosure generally relates to the development and deployment of media applications using NBMP systems. More specifically, the present disclosure describes a method and apparatus for instance-level configuration of functions used in NBMP workflows. An exemplary mechanism is provided for configuring different instances of the same function in various tasks in a media processing workflow with customized configurations and constraints based on the format of the function's general configuration descriptor.

[0006] In some example implementations, a signaling method for generating an NBMP workflow on a cloud-based platform for a media processing application is disclosed. The method may include determining an NBMP task from among multiple NBMP tasks in the NBMP workflow of the media processing application, identifying a feature from a feature repository to be used by the NBMP task, associating the feature with an instance identifier, where the instance identifier uniquely distinguishes an instance of the feature in the NBMP task of the multiple NBMP tasks from other instances of the feature in other NBMP tasks, obtaining a configuration descriptor data structure for the feature from the feature repository, determining a set of restrictions for the instance of the feature in the NBMP task, applying the set of restrictions to the configuration descriptor data structure and generating a feature restriction data structure by using the same format as the configuration descriptor data structure, where the feature restriction data structure is uniquely identified by the instance identifier, and building a process descriptor for the NBMP workflow, including the feature restriction data structure paired with the instance identifier for signaling instance-dependent restrictions of the feature to an NBMP workflow manager.

[0007] In the above exemplary implementation, the configuration descriptor data structure contains a set of parameter configurations that are independent of the instance of the function.

[0008] In any one of the above example implementations, the set of instance-independent parameter configurations includes a set of parameter ranges for parameters associated with the function.

[0009] In any one of the above example implementations, at least one parameter range of the set of parameter ranges includes a numeric range.

[0010] In any one of the above example implementations, at least one parameter range of the set of parameter ranges includes a set of optional choices.

[0011] In any one of the above example implementations, the set of constraints includes further instance-dependent constraints on the set of parameter ranges.

[0012] In any one of the above example implementations, at least one of the sets of constraints includes limiting at least one of the parameters associated with the feature to a single numeric value.

[0013] In any one of the above example implementations, at least one of the sets of constraints includes limiting at least one of the parameters associated with the feature to a single option.

[0014] In any one of the above example implementations, the method may further include identifying a plurality of functions to be used by a plurality of NBMP tasks from a function repository, wherein use of each function in each task is attributed to a unique function instance, and constructing a connectivity map between the function instances as part of the process descriptor, wherein each of the function instances is associated with a unique function instance identifier.

[0015] In some other example implementations, a method for generating an NBMP workflow on a cloud-based platform for media processing applications is disclosed. The method may include receiving an NBMP workflow descriptor document, extracting from the NBMP workflow descriptor document a function restriction data structure associated with a function from a function repository and extracting an instance identifier attributable to the function restriction data structure, where the instance identifier uniquely identifies an instance of use of the function in an NBMP task of the NBMP workflow, the function restriction data structure being instance-dependent and constructed according to a format of a configuration descriptor data structure for the function in the function repository, extracting from the function restriction data structure a set of instance-dependent restrictions on the function, and generating an NBMP workflow according to the NBMP workflow descriptor document and the instance-dependent restrictions of the function.

[0016] Aspects of the present disclosure also provide an electronic device or system including a circuit or processor for executing computer instructions forming a memory for performing any one of the above method implementations.

[0017] Aspects of the present disclosure also provide a non-transitory computer-readable medium storing instructions configured, when executed by an electronic device or system, to cause the electronic device or system to perform any one of the above method implementations.

[0018] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and accompanying drawings. [Brief explanation of the drawings]

[0019] [Figure 1] 1 is an exemplary schematic diagram of a media communication system applicable to media applications, in accordance with one or more embodiments of the present disclosure. [Figure 2]FIG. 1 illustrates an exemplary computing environment for media applications. [Figure 3] FIG. 1 is an exemplary block diagram of an NBMP system in accordance with one or more embodiments of the present disclosure. [Figure 4] FIG. 1 illustrates an exemplary data and logic flow in accordance with one or more embodiments of the present disclosure. [Figure 5] FIG. 10 illustrates another exemplary data and logic flow in accordance with one or more embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0020] Cloud Computing Environment for Media Processing 1 illustrates a diagram of an exemplary computing environment 100 in which the methods, apparatuses, and systems described herein may be implemented, in accordance with various exemplary embodiments. As shown in FIG. 1, computing environment 100 may include one or more user devices 110 (referred to below in the singular for simplicity only), a computing platform 120, and a communications network 130. The various devices and components of environment 100 may be interconnected via wired, wireless, or a combination of wired and wireless connections in communications network 130.

[0021] User device 110 includes one or more devices that can receive, generate, store, process, and / or provide information related to computing platform 120. For example, user device 110 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smartphone, a wireless phone, etc.), a wearable device (e.g., smart glasses or a smart watch, etc.), or a similar device. In some implementations, user device 110 may receive information from and / or transmit information to platform 120.

[0022] Computing platform 120 includes one or more devices as described elsewhere herein. In some implementations, computing platform 120 may include a cloud server or a group of cloud servers. The cloud server or group of cloud servers may be centrally located or geographically distributed. In some implementations, computing platform 120 may be designed modularly so that software components may be swapped in or out according to particular needs. Thus, computing platform 120 may be easily and / or quickly reconfigured for different uses.

[0023] 1, computing platform 120 may be hosted in a cloud computing environment 122. In particular, although the implementations described herein describe platform 120 as being hosted within cloud computing environment 122, in some implementations platform 120 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0024] A cloud computing environment 122 may be configured to host platform 120. Cloud computing environment 122 may provide services such as computation, software, data access, storage, etc. that do not require end-user (e.g., user device 110) knowledge of the physical location and configuration of the system(s) and / or device(s) hosting computing platform 120. As shown in the example of FIG. 1, cloud computing environment 122 may include a group of computing resources 124 (collectively referred to as “computing resources 124” and individually as “computing resource 124”).

[0025] Computing resources 124 include one or more personal computers, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resources 124 may be provided on computing platform 120. Cloud resources may include compute instances running within computing resources 124, storage devices provided within computing resources 124, data transfer devices provided by computing resources 124, etc. In some implementations, computing resources 124 may communicate with other computing resources 124 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0026] As further shown in FIG. 1, computing resources 124 may include a group of cloud resources, such as one or more applications (“APP”) 124-1, one or more virtual machines (“VM”) 124-2, virtualized storage (“VS”) 124-3, and one or more hypervisors (“HYP”) 124-4.

[0027] Application 124-1 may include one or more software applications that may be provided to or accessed by user device 110 and / or platform 120. Application 124-1 may eliminate the need to install and run software applications on user device 110. For example, application 124-1 may include software associated with platform 120 and / or any other software that may be provided via cloud computing environment 122. In some implementations, one application 124-1 may send and receive information to one or more other applications 124-1 via virtual machine 124-2.

[0028] Virtual machine 124-2 may include a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 124-2 may be either a system virtual machine or a process virtual machine, depending on its level of use and the degree to which virtual machine 124-2 corresponds to any real machine. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system (“OS”). A process virtual machine may execute a single program and support a single process. In some implementations, virtual machine 124-2 may run on behalf of a user (e.g., user device 110) and manage various aspects of the infrastructure of cloud computing environment 122, such as data management, synchronization, or long-term data transfer.

[0029] Virtualized storage 124-3 may include one or more storage systems and / or one or more devices that use virtualization technology within the storage systems or devices of computing resource 124. In some implementations, within the context of a storage system, types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage so that the storage system can be accessed regardless of whether it is physical or heterogeneous. The separation may allow flexibility for storage system administrators to manage storage for end users. File virtualization may help eliminate dependencies between data accessed at the file level and where the file is physically stored. Eliminating such dependencies may enable performance optimization of storage usage, server consolidation, and / or nondisruptive file migration.

[0030] The hypervisor 124-4 may provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer, such as the computing resource 124. The hypervisor 124-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of different operating systems may share virtualized hardware resources.

[0031] Network 130 may include one or more wired and / or wireless networks. For example, network 130 may include a cellular network (e.g., a fifth-generation (5G) network, a long-term evolution (LTE) network, a third-generation (3G) network, a WiMax network, a code division multiple access (CDMA) network, etc.), a Wi-Fi network, a public local area mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc., and / or a combination of these or other types of networks.

[0032] The number and arrangement of devices and networks shown in Figure 1 are provided as an example. In practice, there may be additional, fewer, different, or differently arranged devices and / or networks than those shown in Figure 1. Furthermore, two or more devices shown in Figure 1 may be implemented within a single device, or a single device shown in Figure 1 may be implemented as multiple distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment 100 may perform one or more functions described as being performed by another set of devices in environment 100.

[0033] Figure 2 shows a block diagram of example components of one or more devices of Figure 1. Device 200 may correspond to user device 110 and computing platform 120, and any components thereof. As shown in Figure 2, device 200 may include a communication bus 210, a processor 220, a memory 230, a storage component 240, an input component 250, an output component 260, and a communication interface 270.

[0034] The communication bus 210 may include components that enable communication between the components of the device 200. The processor 220 may be implemented in hardware, firmware, or a combination of hardware and software. The processor 220 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or another type of processing component. In some implementations, the processor 220 may include one or more processors that can be programmed to perform functions. The memory 230 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by the processor 220.

[0035] Storage component 240 may store information and / or software related to the operation and use of device 200. For example, storage component 240 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium along with a corresponding drive.

[0036] Input components 250 may include components (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone) that enable device 200 to receive information, such as through user input. Additionally or alternatively, input components 250 may include sensors for sensing environmental information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output components 260 may include components (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)) that provide output information from device 200.

[0037] Communications interface 270 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable device 200 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communications interface 270 may enable device 200 to receive information from and / or provide information to another device. For example, communications interface 270 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0038] Device 200 may perform one or more processes described herein. Device 200 may perform these processes in response to processor 220 executing software instructions stored by a non-transitory computer-readable medium, such as memory 230 and / or storage component 240. A computer-readable medium is defined herein as a non-transitory memory device. A memory device may include memory space within a single physical storage device or memory space distributed across multiple physical storage devices.

[0039] Software instructions may be loaded into memory 230 and / or storage component 240 from another computer-readable medium or from another device via communications interface 270. When executed, the software instructions stored in memory 230 and / or storage component 240 may cause processor 220 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0040] The number and arrangement of components shown in Figure 2 are provided by way of example only. In practice, device 200 may include additional, fewer, different, or differently arranged components than those shown in Figure 2. Additionally or alternatively, a set of components (e.g., one or more components) of device 200 may perform one or more functions described as being performed by another set of components of device 200.

[0041] Network-Based Media Processing Media information, including both media storage and media processing, may be cloudified, for example, in the exemplary cloud computing environment described. Cloud processing of media may generally include obtaining input from a media source, processing the input according to one or more workflows, and generating one or more outputs that are sent to a media sink or destination. Cloudification of media processing workflows may help achieve greater resource efficiency, ensure scalability, and provide faster, larger-scale, and lower-cost deployment of media services. Cloud-based media processing may be particularly well-suited for efficiently processing a variety of newly developed media content, services, experiences, and processing tools, including, but not limited to, virtual reality (VR), augmented reality (AR), 3D and beyond content, and artificial intelligence (AI) tools.

[0042] An example of such a platform may be referred to as network-based media processing (NBMP). In NBMP, media service providers may need to deploy their workflows across different cloud platforms and geographic locations. Workflows may be configured to perform various media processing functions on a mix of cloud, edge, and on-premises gateways. In some example implementations, a microservices design pattern may be adopted for NBMP for greater scalability, reusability, isolation, and test stability of different media processing functions.

[0043] In some implementations, the NBMP platform may be designed to provide a unified abstraction layer for configuring, controlling, managing, and monitoring flexible media processing workflows that is independent of (or dependent on) the underlying cloud infrastructure or platform. The NBMP layer may define an architecture, APIs, media and metadata formats for discovering media processing capabilities, describing media workflows, deploying media processing workflows, configuring runtime tasks, monitoring for bad behavior, and taking corrective action.

[0044] For ease of description, this disclosure will adopt the terms and nomenclature as set forth below.

[0045] Functional Description: A detailed description of the media processing functionality, including input and output description details, requested media processing, and requirements.

[0046] Feature Repository: A storage place where NBMP features are retrieved by the NBMP Workflow Manager or NBMP Source.

[0047] Media Processing Entity: An entity that performs one or more media processing tasks.

[0048] Media Resource: Media data ingested by a media source and sent to a media processing entity in the NBMP system.

[0049] Media Sink: An entity that consumes the output of an NBMP workflow through an existing delivery method.

[0050] Media Source: The entity that provides the raw media content to be processed, such as a digital camera, microphone, encoder, or persistent storage.

[0051] NBMP Format: The media format exchanged between media sources and media processing entities within an NBMP system, and between individual media processing entities within an NBMP system.

[0052] NBMP Capabilities: Implementation of standalone and self-contained media processing operations and corresponding descriptions of those operations.

[0053] NBMP Publish Format: The media format of the content sent from the media processing entity to the media sink.

[0054] NBMP Source: An entity that provides triggers and describes media processing within a network.

[0055] NBMP System: A system for processing media across one or more processing entities in a network, the system consisting of a media source, an NBMP source, an NBMP workflow manager, a function repository, media processing entity(ies) and media sink(s).

[0056] NBMP Workflow: One or more connected tasks that accomplish the requested media processing, which may be presented in a variety of forms.

[0057] NBMP Workflow Manager: The entity that provisions tasks and connects them to create a complete workflow based on the workflow description and the functional description.

[0058] Supplemental Information: Metadata or auxiliary information associated with media data or media processing operations.

[0059] Task: A runtime instance of an NBMP function that executes within a media processing entity.

[0060] Task Description: A description of the runtime details of the task, including input and output description details, requirements, and configuration information.

[0061] Workflow Description: A description of the media processing details, including input and output description details, requested media processing, and workflow requirements.

[0062] Figure 1 illustrates an exemplary NBMP system 300. As shown in Figure 3, the NBMP system 300 may include one or more NBMP sources 310, an NBMP workflow manager 320, one or more feature repositories 330, one or more media processing entities (MPEs) 350, one or more media sources 360, and one or more media sinks 370. The NBMP sources 310, the NBMP workflow manager 320, the feature repository 330, the MPEs 340, the media sources 350, and the media sinks 360 may include or be implemented by at least one or more processors and memory storing code configured to cause the at least one or more processors to perform the functions of the NBMP sources 310, the NBMP workflow manager 320, the feature repository 330, the MPEs 340, the media sources 360, and the media sinks 360, respectively.

[0063] The NBMP source 310 may request the NBMP workflow manager 320 to create a workflow containing tasks to be performed by one or more media processing entities (MPEs) 340 by sending a workflow description document (WDD) to the NBMP workflow manager 320. The WDD may include several descriptors, each of which may contain several parameters. These descriptors may include details such as input and output data, required functions, and workflow requirements. The WDD may include a set of task descriptions in task descriptors and a task connectivity map that connects the inputs and outputs of tasks to be performed by one or more of the media processing entities 340. When the NBMP workflow manager 320 receives such information from the NBMP source 310, the NBMP workflow manager 320 may create a workflow by instantiating tasks based on function names and connecting the tasks according to the connectivity map.

[0064] The NBMP source 310 may communicate the WDD to the NBMP workflow manager 320 via the NBMP workflow API 311. The NBMP source 310 may also communicate feature descriptions with the feature repository 330 via a feature discovery API 313 to obtain feature descriptions of the features stored in the feature repository 330. These features may include media processing features stored in the feature repository 330, such as features for media decoding, feature point extraction, camera parameter extraction, projection methods, seam information extraction, blending, post-processing, and encoding. The NBMP workflow manager 320 may communicate with the feature repository 330 via a feature discovery API 312, which may be the same or a different API as the feature discovery API 313, and may further communicate with one or more of the MPEs 340 via an API 314 (e.g., an MPE API).

[0065] In some example implementations, NBMP source 310 may request NBMP workflow manager 320 to create a workflow using a set of keywords. For example, NBMP source 310 may send NBMP workflow manager 320 a WDD that may include a set of keywords that NBMP workflow manager 320 may use to identify appropriate functions stored in function repository 330. When NBMP workflow manager 320 receives such information from NBMP source 310, NBMP workflow manager 320 may create the requested workflow by searching for appropriate functions using keywords that may be specified in process descriptors in the WDD, and may use other descriptors in the WDD to define tasks and connect the tasks to create the workflow.

[0066] The NBMP workflow manager 320 may use the API 314 to set up, configure, manage, and monitor one or more tasks 341 of a workflow that can be executed by one or more MPEs 340. In some example implementations, the NBMP workflow manager 320 may use the API 314 to update and destroy tasks. To configure, manage, and monitor the tasks 341 of a workflow, the NBMP workflow manager 320 may send messages, such as requests, to one or more of the MPEs 340, and each message may have several descriptors, each of which has several parameters. The tasks 341 may each include a media processing function 342 and a configuration 343 for the media processing function 342.

[0067] The MPE 340 may provision one or more tasks 341. The NBMP workflow manager 320 may communicate with the tasks 341 via an API 315 (e.g., an NBMP task API). The NBMP workflow manager 320 may use the API 315 to set up, configure, manage, and monitor one or more tasks 341 of a workflow being executed by one or more MPEs 340. To configure, manage, and monitor the tasks 341 of a workflow, the NBMP workflow manager 320 may send messages, such as requests, to one or more of the MPEs 340 and / or tasks 341, where each message may have several descriptors, and each of the descriptors may be associated with several parameters. Furthermore, communication between the NBMP source 310, the NBMP workflow manager 320, the capability repository 330, and the MPE 340 may form a control flow.

[0068] Each task 341 may invoke a media processing function 343 according to a configuration 342 for the media processing function 343. Each task 341 within each media processing entity 340 may also communicate with each other to facilitate data flow between the tasks. In some example implementations, the NBMP workflow manager 320 may select a task based on the task's description in the WDD and search the function repository 330 via the function discovery API 312 to identify an appropriate function to perform as the task 341 for the current workflow. One or more MPEs 340 may be configured to receive media content from a media source 350, process the media content according to a workflow, including processing the media in task 341, and output the processed media content to a media sink 360. In some example implementations, one or more MPEs 340 may provide multiple media flows 316 and 317 between the media source 350 and the media sink 360 in parallel, respectively.

[0069] Media source 350 may be configured to store media and may be integrated with or separate from NBMP source 310. In some example implementations, NBMP workflow manager 320 may notify NBMP source 310 when a workflow is prepared, and media source 350 may send media content to one or more MPEs 340 based on the notification, which may perform corresponding tasks, process the media content, generate output, and send the output media to media sink 360. Communication between media source 350, MPE 340, and media sink 360 may form a data flow (as opposed to the control flow described above).

[0070] Feature configuration in the feature repository The feature repository, described above and shown as component 330 in FIG. 3, is important in that it supplies the functions and tools used by the various tasks instantiated by MPE 340 for a workflow. Each function in feature repository 330 may be associated with a feature description. Each feature description may be stored in the feature repository as a data structure according to a predefined format. Such a data structure may be referred to as a feature descriptor. A feature descriptor often includes, for example, a configuration of parameters associated with the corresponding function, including a description of the parameters, their types, ranges, etc. Such a configuration description may be referred to as a configuration descriptor for the function.

[0071] For example, a transcoder function identified by "TRANS-VIDEO-292518" may have the exemplary predefined configuration parameters shown in Table 1 below.

[0072] [Table 1]

[0073] The ranges of the various parameters provide general limits on the parameter choices for this transcoder function.

[0074] In an exemplary implementation, the corresponding configuration description data structure may be constructed as follows: Listing 1 { “parameters”:[ { “name”:“codec”, “id”:1, “description”:“codec type”, “datatype”:“string”, "values":[ { “name”:“AVC”, “id”:11, “restrictions”:[“”] }, { “name”:“HEVC”, “id”:12, “restrictions”:[“”] }, { “name”:“VVC”, “id”:13, “restrictions”:[“”] } ] }, { “name”:“width”, “description”:“width in pixels”, “datatype”:“integer”, "values":[ { “name”:“width”, “id”:21, "restrictions":{ “min-value”:16, “max-value”:15360} } ] }, { “name”:“height”, “id”:3, “description”:“height in pixels”, “datatype”:“integer”, "values":[ { “name”:“height”, “id”:31, "restrictions":{ “min-value”:16, “max-value”:8640 } } ] }, { “name”:“bitrate”, “id”:4, “description”:“bitrate in kb / sec”, “datatype”:“integer”, "values":[ { “name”:“bitrate”, “id”:41, "restrictions":{ “min-value”:100, “max-value”:100000 } } ] } ] }

[0075] Workflow Description Document (WDD) for Functional Instances As described above, the WDD may be provided by the NBMP source 310 to the NBMP workflow manager 320 to generate a workflow according to the WDD. Thus, the WDD contains all the information that may be needed for the NBMP workflow manager 320 to identify required functions from the function repository 330 and determine relationships between various tasks.

[0076] Among other data, the WDD may include process descriptors that specify tasks, connections between various tasks, and functions used by each task. For example, the process descriptors may include a connection map for task / function objects that specifies the relationships between various tasks / functions (e.g., input / output relationships).

[0077] In some example implementations, the same feature from feature repository 330 of FIG. 3 may be used in multiple tasks. Use of the same feature in each of multiple tasks may be treated as a separate instance of the same feature and may therefore be attributed an instance identifier in the WDD. Thus, a feature within a task may be identified by at least two parameters: a task / feature identifier that uniquely identifies the corresponding task or feature used, and an instance identifier that is used when two or more tasks use the same feature. In this way, the instance identifier identifies the specific instance of the feature used for the task.

[0078] In one particular example, the above transcoder function "TRANS-VIDEO-292518" may be used by two tasks, "task-1" and "task-2." The two tasks may be connected as "task-1" to "task-2" (e.g., meaning that the output of task-1 goes to the input of task-2). An exemplary task / function connection map element is shown in Listing 2 below. Listing 2 "from":{ “id”:“TRANS-VIDEO-292518”, “instance”:“task-1”, “port-name”:“12” }, "to":{ “id”:“TRANS-VIDEO-292518”, “instance”:“task-2”, “port-name”:“12” }

[0079] In the above example, a first task is to be connected to a second task. Both tasks use the same function. However, to be distinguishable from one another, each of the same functions in the two tasks includes a unique "instance" value as an instance identifier. As described in further detail below, distinguishing between different instances of the same function can facilitate adaptive function configuration of tasks and enable distinguishing between configurations of different instances of the same function instantiated in different tasks.

[0080] In some further example implementations, the processing descriptor may further include an array of feature restriction objects. Each feature restriction object may define a specific restriction that applies to a feature. Various restrictions may be imposed on a feature. Correspondingly, each feature restriction object may include several different objects, each associated with one type of restriction on the feature. Some of these types of restrictions may be general and instance-independent. Thus, the corresponding objects may not need to be associated with a specific instance identifier of the feature. However, some other types of restrictions may be instance-dependent, and therefore, the objects associated with those restriction types may be further tagged with a feature instance identifier.

[0081] One of the various types of constraints may relate to parameter constraints of a function, which may relate to a set of constraints on, for example, parameter ranges, etc.

[0082] As an example of parameter restrictions, as described above, for a transcoder feature identified by "TRANS-VIDEO-292518," the range of values ​​for various parameters may be restricted to a subset of the general ranges of the parameters specified by the configuration description in the feature repository, as shown in Table 1. Example restrictions may result in a parameter range configuration for "TRANS-VIDEO-292518" as shown in Table 2 below, which applies when used in a particular task.

[0083] [Table 2]

[0084] Such parameter restrictions may be instance-dependent. Thus, a parameter restriction object under a higher-level feature restriction object for such parameter restrictions may be associated with a particular instance identifier. Such a parameter restriction object may include a data structure for describing the parameter restrictions. As an example, such a data structure may be similar in form to the configuration descriptor described above in connection with Listing 1 for a feature configuration description in a feature repository.

[0085] For example, a particular parameter constraint description within a parameter constraint object within an array of feature constraint objects associated with a particular instance of a feature having the parameter constraints of Table 2 may be described using the data structure in Listing 3 below. Listing 3 { “parameters”:[ { “name”:“codec”, “id”:1, “description”:“codec type”, “datatype”:“string”, "values":[ { “name”:“HEVC”, “id”:12, “restrictions”:[“”] } ] }, { “name”:“width”, “id”:2, “description”:“width in pixels”, “datatype”:“integer”, “values”:[ { “name”:“width”, “id”:21, “restrictions”:{ “min-value”:1920, “max-value”:1920 } } ] }, { “name”:“height”, “id”:3, “description”:“height in pixels”, “datatype”:“integer”, “values”:[ { “name”:“height”, “id”:31, “restrictions”:{ “min-value”:1080, “max-value”:1080 } } ] }, { “name”:“bitrate”, “id”:4, “description”:“bitrate in kb / sec”, “datatype”:“integer”, “values”:[ { “name”:“bitrate”, “id”:41, "restrictions":{ “min-value”:3000, “max-value”:3000 } } ] } ] }

[0086] Thus, in some example implementations, a WDD for generating a task flow may include a process descriptor. The process descriptor may include a connectivity map. The process descriptor may further include an array of feature constraint objects. Each feature constraint object may be associated with a feature and an instance identifier of the feature. Thus, some feature constraint objects in the array may be associated with the same feature but with different instance identifiers. Furthermore, each feature constraint object may include multiple lower-layer objects for different types of feature constraints. One of these lower-layer objects may describe parameter constraints for the feature instance. Such parameter constraint objects may include a data structure (e.g., Listing 3) for describing the parameter constraints. Such a data structure may be similar in form to the configuration descriptor used in the feature repository to describe general feature parameter configurations (e.g., Listing 1).

[0087] In some example implementations, a WDD for generating a task flow may include a process descriptor. The process descriptor may include a connectivity map. The process descriptor may further include an array of function restriction objects. Each of the function restriction objects may be associated with a function. Furthermore, each of the function restriction objects may include multiple lower-layer objects for different types of function restrictions. One or more of these lower-layer objects may be used to describe parameter restrictions for a function instance of the function. Each such parameter restriction object may include a data structure for describing the parameter restrictions for that particular function instance (e.g., List 3). Such a data structure may be similar in form to the configuration descriptor used in the function repository to describe general function parameter configurations (e.g., List 1). In such implementations, an array of function restriction objects may be associated with different functions (regardless of the instance). However, second-level restriction objects of different restriction types, such as parameter restriction objects, may be associated with the instance identifier of the function. Thus, there may be multiple lower-level restriction objects (e.g., parameter restriction objects) that describe the same type of restriction but for different instances of the function.

[0088] FIG. 4 shows an example data and logic flow 400 for a signaling method for generating an NBMP workflow in a cloud-based platform for a media processing application. In step 410, an NBMP task among a plurality of NBMP tasks in the NBMP workflow of the media processing application is determined. In step 420, a feature from a feature repository to be used by the NBMP task is identified. In step 430, the feature is associated with an instance identifier, which uniquely distinguishes an instance of the feature in an NBMP task among the plurality of NBMP tasks from other instances of the feature in other NBMP tasks. In step 440, a configuration descriptor data structure for the feature is obtained from the feature repository. In step 450, a set of constraints for the instance of the feature in the NBMP task is determined. In step 460, a feature constraint data structure is generated by applying the set of constraints to the configuration descriptor data structure and using the same format as the configuration descriptor data structure, where the feature constraint data structure is uniquely identified by the instance identifier. Finally, in step 470, a process descriptor is constructed for the NBMP workflow that includes a function restriction data structure paired with an instance identifier for signaling instance-dependent restrictions on functions to the NBMP workflow manager.

[0089] 5 shows another example data and logic flow 500 for generating an NBMP workflow in a cloud-based platform for media processing applications. In step 510, an NBMP workflow descriptor document is received. In step 520, a function restriction data structure associated with a feature from a function repository and an instance identifier resulting from the function restriction data structure are extracted from the NBMP workflow description document, where the instance identifier uniquely identifies an instance of use of the feature in an NBMP task of the NBMP workflow, and the function restriction data structure is instance-dependent and constructed according to the format of the feature's configuration descriptor data structure in the function repository. In step 530, a set of instance-dependent restrictions on the feature is extracted from the function restriction data structure. In step 540, an NBMP workflow is generated according to the NBMP workflow description document and the instance-dependent restrictions on the feature.

[0090] While this disclosure describes several exemplary embodiments, there are alterations, permutations, and various substitute equivalents that fall within the scope of this disclosure. It will thus be appreciated that those skilled in the art will be able to devise numerous systems and methods that, although not explicitly shown or described herein, embody the principles of the present disclosure and are therefore within the spirit and scope of the present disclosure. [Explanation of symbols]

[0091] 100 Computing Environments 110 User Devices 120 Platform 122 Cloud Computing Environment 124 computing resources 124-1 Application 124-2 Virtual Machine 124-3 Virtualized Storage 124-4 Hypervisor 130 Network 200 devices 210 Bus 220 processors 230 memory 240 Storage Components 250 Input Components 260 Output Components 270 Communication Interface 300 NBMP System 310 NBMP Source 311 NBMP Workflow API 312 Feature Discovery API 313 Feature Discovery API 314 API 315 API 316 Media Flow 317 Media Flow 320 NBMP Workflow Manager 330 Feature Repository 340 Media Processing Entities 341 tasks 342 Configuration 343 Media Processing Functions 350 media sources 360 Media Sync 370 Media Sync 400 Logical Flow 500 Logical Flow

Claims

1. A signaling method for generating a network-based media processing (NBMP) workflow in a cloud-based platform for media processing applications, executed by at least one processor, the method comprising: determining an NBMP task from among a plurality of NBMP tasks in an NBMP workflow of the media processing application; identifying a function from a function repository to be used by the NBMP task; associating the function with an instance identifier, the instance identifier uniquely distinguishing an instance of the function in the NBMP task of the plurality of NBMP tasks from other instances of the function in other NBMP tasks; obtaining a configuration descriptor data structure for the feature from the feature repository; determining a set of constraints for the instance of the function within the NBMP task; applying the set of restrictions to the configuration descriptor data structure and generating a feature restriction data structure by using the same format as the configuration descriptor data structure, the feature restriction data structure being uniquely identified by the instance identifier; constructing a process descriptor for the NBMP workflow, the process descriptor including the function restriction data structure paired with the instance identifier for signaling instance-dependent restrictions of the function to an NBMP workflow manager; A signaling method comprising:

2. 2. The signaling method of claim 1, wherein the configuration descriptor data structure includes a set of parameter configurations that are independent of the instance of the function.

3. 3. The signaling method of claim 2, wherein the set of instance-independent parameter configurations includes a set of parameter ranges for parameters associated with the function.

4. 4. The signaling method of claim 3, wherein at least one parameter range of the set of parameter ranges comprises a numerical range.

5. 4. The signaling method of claim 3, wherein at least one parameter range of the set of parameter ranges comprises a set of optional choices.

6. 4. The signaling method of claim 3, wherein the set of constraints includes further instance-dependent constraints on the set of parameter ranges.

7. 7. The signaling method of claim 6, wherein at least one of the sets of restrictions includes restricting at least one of the parameters associated with the feature to a single numerical value.

8. 7. The signaling method of claim 6, wherein at least one of the sets of restrictions includes restricting at least one of the parameters associated with the feature to a single option.

9. identifying a plurality of functions to be used by the plurality of NBMP tasks from the function repository, wherein each function usage in each task is attributed to a unique function instance; constructing a connectivity map between the function instances as part of the process descriptor, each of the function instances being associated with a unique function instance identifier; 9. The signaling method according to claim 1, further comprising:

10. 10. An electronic device for signaling a workflow manager for generating an NBMP workflow in a cloud-based platform for media processing applications, the electronic device configured to perform the method of claim 1, the electronic device comprising: a memory for storing instructions; and a processor for executing the instructions to perform the method of claim 1.

11. 10. A computer program comprising instructions configured, when executed by at least one processor, to cause the at least one processor to perform the method of claim 1.

12. A method for generating an NBMP workflow in a cloud-based platform for media processing applications, executed by at least one processor, the method comprising: receiving an NBMP workflow descriptor document; extracting from the NBMP workflow descriptor document a function restriction data structure associated with a function from a function repository and extracting an instance identifier attributed to the function restriction data structure, the instance identifier uniquely identifying an instance of use of the function in an NBMP task of the NBMP workflow, the function restriction data structure being instance dependent and constructed according to the format of a configuration descriptor data structure for the function in the function repository; extracting from the feature constraints data structure a set of instance-dependent constraints for the feature; generating the NBMP workflow according to the NBMP workflow descriptor document and the instance-dependent restrictions on the functions; A method comprising:

13. 13. An electronic device for generating a workflow in a cloud-based platform for media processing applications, the electronic device comprising: a memory for storing instructions; and a processor for executing the instructions to perform the method of claim 12.

14. 13. A computer program comprising instructions configured, when executed by at least one processor, to cause the at least one processor to perform the method of claim 12.

Images