Tools for conformance of Network-Based Media Processing (NBMP) documents and entities

Abstract

A method, apparatus, and computer-readable storage medium for validating NBMP documents and entities. One method may include invoking an application programming interface (API) corresponding to an API operation supported by the NBMP entity, the API operation relating to at least one of a create operation, an update operation, a search operation, or a delete operation, receiving a response from the NBMP entity, and determining, based on the response, whether the NBMP entity passes an API test corresponding to the API operation.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is based on and claims the benefit of priority to U.S. Provisional Application No. 63 / 332,613, filed April 19, 2022, and U.S. Nonprovisional Application No. 18 / 301,657, filed April 17, 2023, each of which is incorporated by reference in its entirety herein.

[0002] This disclosure relates generally to media streaming technologies, including network-based media processing (NBMP). More specifically, the disclosed technologies include methods and apparatus for tools to verify and ensure conformance of NBMP documents and entities. [Background technology]

[0003] The Background of the Invention described herein is intended to provide a general overview of the background of the disclosure. To the extent described in the Background of the Invention section, the work of the currently named inventors and other aspects of the description that may not have attained the status of prior art at the time of filing of this application are not admitted, expressly or impliedly, as prior art to the present disclosure.

[0004] Networks and cloud platforms may be used to run a variety of applications. The Network-Based Media Processing (NBMP) standard provides specifications for defining, instantiating, and executing workflows on cloud platforms. Workflows can be executed in parts, task by task, or group by group of tasks at each point in time. NBMP shows great potential for improving media processing efficiency, faster and less expensive deployment of media services, and the ability to provide large-scale deployments by leveraging public, private, or hybrid cloud services. NBMP requires various multimedia service providers and network / cloud service providers to collaborate to provide customized immersive media services to customers. Summary of the Invention [Problem to be solved by the invention]

[0005] One or more exemplary embodiments of the present disclosure provide methods and apparatus for media streaming technologies, including NBMP. [Means for solving the problem]

[0006] An aspect of the present disclosure provides a method for validating an NBMP document in an NBMP system. The method may be performed by an NBMP document validator operating on at least one processor and may include obtaining an NBMP document, the NBMP document including at least one of a description document or a descriptor document, selecting a baseline schema and baseline rules based on the NBMP document, validating a schema of the NBMP document based on the baseline schema, validating a semantic of the NBMP document based on the baseline rules, and determining whether the NBMP document complies with the NBMP standard based on a result of validating the schema and semantic of the NBMP document.

[0007] Aspects of the present disclosure also provide a method for validating a network-based media processing (NBMP) entity in an NBMP system. The method may be performed by an NBMP entity verifier operating on at least one processor and may include invoking an application programming interface (API) corresponding to an API operation supported by the NBMP entity, where the API operation is related to at least one of a create operation, an update operation, a search operation, or a delete operation, receiving a response from the NBMP entity, and determining, based on the response, whether the NBMP entity passes an API test corresponding to the API operation.

[0008] Aspects of the present disclosure also provide a device or apparatus that includes circuitry configured to perform any of the above method embodiments.

[0009] Aspects of the present disclosure also provide a non-transitory computer readable medium storing instructions that, when executed by a computer, cause the computer to perform any of the above method embodiments.

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

[0011] [Figure 1] 1 is a schematic diagram of a communication system in accordance with one or more embodiments of the present disclosure. [Diagram 2] 1 illustrates a simplified example of a streaming environment in accordance with one or more embodiments of the present disclosure. [Diagram 3] FIG. 1 illustrates a block diagram of an NBMP system in accordance with one or more embodiments of the present disclosure. [Figure 4] 1 shows an example of an NBMP schema validator and an example of an NBMP semantic validator. [Figure 5a] Here is an example of an NBMP entity validator. [Figure 5b] Here is an example of an NBMP entity validator. [Figure 5c] Here is an example of an NBMP entity validator. [Figure 5d] Here is an example of an NBMP entity validator. [Figure 6] 1 illustrates a flowchart of a method according to an exemplary embodiment of the present disclosure. [Figure 7] FIG. 1 illustrates a schematic diagram of a computer system according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Figure 1 is a diagram of an environment 100 in which the methods, apparatus, and systems described herein may be implemented, according to an embodiment. As shown in Figure 1, the environment 100 may include a user device 110, a platform 120, and a network 130. The devices of the environment 100 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections.

[0013] User device 110 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to 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 platform 120 and / or transmit information to platform 120.

[0014] Platform 120 includes one or more devices as described elsewhere herein. In some implementations, platform 120 may include a cloud server or a group of cloud servers. In some implementations, platform 120 may be designed to be modular such that software components can be swapped in and out depending on what is needed at the time. Thus, platform 120 may be easily and / or quickly reconfigured for different uses.

[0015] 1, platform 120 may be hosted in a cloud computing environment 122. In particular, although the implementations described herein have been described as providing platform 120 by hosting in cloud computing environment 122, in some implementations platform 120 may be non-cloud based (i.e., implemented outside of a cloud computing environment) or may be partially cloud based.

[0016] Cloud computing environment 122 includes an environment that hosts platform 120. Cloud computing environment 122 may provide services, such as computing, software, data access, storage, etc., that do not require end-user (e.g., user device 110) information about the physical location and configuration of one or more systems and / or one or more devices that host platform 120. As shown, cloud computing environment 122 may include a group of computing resources 124 (collectively referred to as “computing resources 124” and individually referred to as “computing resource 124”).

[0017] Computing resources 124 may 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 provide hosting for platform 120. Cloud resources may include computing 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.

[0018] As further shown in FIG. 1, computing resources 124 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.

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

[0020] The virtual machine 124-2 includes a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. The virtual machine 124-2 may be either a system virtual machine or a process virtual machine depending on the application and the degree to which the virtual machine 124-2 matches any real-world machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system (OS). A process virtual machine can execute only one program and support only one process. In some implementations, the virtual machine 124-2 may execute on behalf of a user (e.g., the user device 110) and manage the infrastructure of the cloud computing environment 122, such as data management, synchronization, or long-term data transfer.

[0021] Virtualized storage 124-3 includes one or more storage systems and / or one or more devices that use virtualization techniques within the storage systems or devices of computing resources 124. In some embodiments, in the context of storage systems, 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 such that the storage system may be accessed from either physical storage or heterogeneous structures. The separation allows storage system administrators more flexibility in how they manage storage for end users. File virtualization allows the removal of dependencies between data being accessed at a given file level and where the file is physically stored. This may allow for optimization of storage usage, server consolidation, and / or smooth file migration.

[0022] 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 provide a virtual operating platform for the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of various operating systems may share virtualized hardware resources.

[0023] 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 land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the public switched telephone network (PSTN)), a private network, an ad-hoc network, an intranet, the Internet, a fiber optic based network, etc., and / or a combination of these or other types of networks.

[0024] The number and arrangement of devices and networks shown in Figure 1 are provided as an example. In practice, there may be more devices and / or networks, fewer devices and / or networks, different devices and / or networks, or different arrangements of devices and / or networks compared to those shown in Figure 1. Furthermore, two or more devices shown in Figure 1 may be implemented in one device, or one 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 of environment 100.

[0025] Figure 2 is a block diagram of example components of one or more devices of Figure 1. Device 200 may correspond to user device 110 and / or platform 120. As shown in Figure 2, device 200 may include a 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.

[0026] The bus 210 includes 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 processor. In some embodiments, the processor 220 includes one or more processors that can be programmed to perform functions. The memory 230 includes 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 used by the processor 220.

[0027] Storage component 240 stores 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, cartridges, magnetic tape, and / or another type of non-transitory computer-readable medium along with a corresponding drive.

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

[0029] 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 be used to 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.

[0030] Device 200 may perform one or more of the processes described herein. Device 200 may perform such 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 in this application as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

[0031] 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 be used to cause processor 220 to perform one or more of the processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more of the processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0032] The number and arrangement of components shown in Figure 2 are provided as an example. In practice, device 200 may include more elements, fewer elements, different elements, or a different arrangement of elements compared to 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.

[0033] For ease of explanation, the present disclosure employs terms and names defined in the NBMP system-related standards, however, the present disclosure is not limited by such terms and names and may be equally applicable to multimedia systems that conform to other standards and perform the same or similar functions as those of the NBMP system.

[0034] Functional Description: A detailed description of the media processing capabilities, including input and output description details, required media processing, requirements, etc.

[0035] Function Repository: A storage location where NBMP functions are searched for by the NBMP Workflow Manager or the NBMP Source.

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

[0037] Media resource: Media data ingested by a media source and transmitted to a media processing entity in the NBMP system.

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

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

[0040] NBMP format: A media format exchanged between media sources and media processing entities within an NBMP system, and between individual media processing entities within an NBMP system.

[0041] NBMP Functions: Implementation of stand-alone and self-contained media processing operations and corresponding descriptions of those operations

[0042] NBMP Publish Format: The media format of the content sent from the Media Processing Entity to the Media Sink.

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

[0044] 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).

[0045] NBMP workflow: a graph of one or more connected tasks that accomplishes a desired media processing task.

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

[0047] Supplemental Information: Metadata or auxiliary information about the media data or media processing operations

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

[0049] Task Description: A description of the run-time details of the task, including input and output details, requirements, configuration information, etc.

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

[0051] In one embodiment of the present disclosure, a network-based media processing (NBMP) system is provided. FIG. 3 illustrates an NBMP architecture 300 according to an embodiment of the present disclosure, which may be implemented for cloud processing. The NBMP system 300 may include an NBMP source 310, an NBMP workflow manager 320, a function repository 330, one or more media processing entities (MPEs) 340, a media source 350, and a media sink 360. The NBMP source 310, the NBMP workflow manager 320, the function repository 330, the MPE 340, the media source 350, and the media sink 360 may include or be implemented by at least one or more processors and a memory storing code configured to cause the at least one or more processors to perform functions of the NBMP source 310, the NBMP workflow manager 320, the function repository 330, the MPE 340, the media source 360, and the media sink 360, respectively.

[0052] The NBMP source 310 can communicate a workflow description with the NBMP workflow manager 320 via the NBMP workflow API 311. The NBMP source 310 can also communicate the feature description with the feature repository 330 via the feature discovery API 313. For example, the NBMP source 310 can send a workflow description document (WDD) to the NBMP workflow manager 320, which can read feature descriptions of features stored in the feature repository 330, where the features are media processing functions stored in the memory of the feature repository 330, such as media decoding, feature point extraction, camera parameter extraction, projection method, seam information extraction, blending, post-processing, and encoding functions. The NBMP workflow manager 320 can communicate with the feature repository 330 via a feature discovery API 312, which can be the same or a different API as the feature discovery API 313, and can communicate with one or more of the MPEs 340 via an API 314 (e.g., an MPE API).

[0053] Alternatively or additionally, the NBMP source 310 may request the NBMP workflow manager 320 to create a workflow using a set of keywords. For example, the NBMP source 310 may send the NBMP workflow manager 320 a workflow description document that may include a set of keywords that the NBMP workflow manager 320 may use to find appropriate functions stored in the function repository 330. When the NBMP workflow manager 320 receives such information from the NBMP source 310, the NBMP workflow manager 320 may create a workflow by searching for appropriate functions using keywords that may be specified in process descriptors of the workflow description document, and may use other descriptors in the workflow description document to provide tasks and connect them to create the workflow. The NBMP workflow manager 320 may include or be implemented by at least one processor and a memory storing code configured to cause the processor to perform at least the functions of the NBMP workflow manager 320.

[0054] The media processing entity (MPE) 340 may include one or more tasks 341. The NBMP workflow manager 320 may also 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 that may be 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, and each message may have several descriptors, each of which has several parameters. Furthermore, the communication between the NBMP source 310, the NBMP workflow manager 320, the capability repository 330, and the MPE 340 may be considered a control flow.

[0055] The tasks 341 may each include a media processing function 343 and a configuration 342 for the media processing function 343. Each of the tasks 341 in each media processing entity 340 may also communicate with each other to facilitate data flow between the tasks. In one embodiment, the NBMP workflow manager 320 may select a task based on the task's description in the WDD and search the capability repository 330 via the capability discovery API 312 to find 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 the task 341 created by the NBMP workflow manager 320, and output the processed media content to a media sink 360. In one embodiment, one or more MPEs 340 may each provide multiple media flows 316 and 317 between the media source 350 and the media sink 360 in parallel.

[0056] Media source 350 may include memory to store media and may be integrated with or separate from NBMP source 310. In one embodiment, 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 that a workflow is prepared, which may send media content to media sink 360. Communication between media source 350, MPE 340, and media sink 360 may be considered a data flow.

[0057] When the workflow manager 320 receives a workflow description document (WDD) from an NBMP client, it selects the media processing functions to be inserted into the workflow. Once a list of tasks that need to be included in the workflow is compiled, the workflow manager connects those tasks to prepare the required workflow.

[0058] In some example implementations, the workflow manager 320 can generate a directed acyclic graph (DAG) from the WDD. Each node in the DAG represents a processing task in the workflow. Each node can receive at least one input and generate at least one output. A link connecting one node to another node in the graph represents conveying the output of the former node as an input to the latter node. In general, an NBMP workflow graph can have multiple inputs and outputs.

[0059] The NBMP system may include three layers: a logical layer, an object layer, and a resource layer. The logical layer may include logical items such as logical descriptions. The object layer may include data objects such as JavaScript Object Notation (JSON) objects. The resource layer may include Representational State Transfer (REST) ​​resources.

[0060] For example, there is a one-to-one relationship between a logical description and the corresponding data objects, data documents, and REST resources.

[0061] NBMP logical items may include parameters, descriptors, and descriptions.

[0062] Workflow Objects (WO), Task Objects (TO), Function Objects (FO), and MPE Functionality Objects (MO) are the realization of the corresponding main descriptor as a JSON object.

[0063] In an exemplary implementation, the Workflow Description Document (WDD), Task Description Document (TDD), Functionality Description Document (FDD), and MPE Functionality Description Document (MDD) are documents that contain a single WO, a single TO, a single FO, and a single MO, respectively. These documents may be JSON objects.

[0064] The workflow resources (WR), task resources (TR), function resources (FR), and MPE function resources (MR) may be, for example, WDDs, TDDs, FDDs, and MDDs, respectively, with valid URLs. These resources may be, for example, REST resources.

[0065] The aforementioned description documents, e.g., WDD, TDD, FDD, WDD, etc., are exchanged between various entities within the NBMP framework, as shown in Figure 3.

[0066] For example, WDDs may be exchanged between the NBMP source 310 and the workflow manager 320. FDDs may be exchanged between the capability repository 330 and the workflow manager 320, or between the capability repository 330 and the NBMP source 310. TDDs may be exchanged between the workflow manager 320 and a task 341. MDDs may be exchanged between the workflow manager 320 and the MPE(s) 340.

[0067] In some example implementations, each of the description documents, such as the WDD, TDD, FDD, and WDD, may be described using a set of descriptors. Each of the descriptors may be associated with a cardinality and additional constraints. The WDD, TDD, FDD, and WDD may be described and presented in a predefined format, such as a JSON format. Similarly, each of the descriptors may be described and presented in a document according to a predefined format, such as a JSON format.

[0068] Illustratively, a description document or descriptor document can be thought of as an implementation or instantiation of the corresponding schema.

[0069] Table 1 shows an example capability description that includes multiple descriptors.

[0070] [Table 1]

[0071] Note that the additional constraints defined in the table above can be used as baseline rules for validating the semantics of FDD.

[0072] The FD defined above may be presented in JSON format. Table 2 below shows an example FDD schema in JSON.

[0073] [Table 2]

[0074] As shown in Tables 1 and 2, an FDD may include multiple descriptors, including required descriptors such as general, input, and output descriptors. There are also other optional descriptors such as processing, requirements, configuration, steps, client-assistant, etc. It should be noted that whether a descriptor is defined as required or optional is for illustrative purposes only. Based on design requirements, the schema may include different descriptors. For example, the same descriptor may be required in one release but defined as optional in another release. Each descriptor may be presented in JSON format, and examples of the descriptors are described below.

[0075] The FD schema in JSON format defined above may be used as a baseline schema for validating the FDD schema.

[0076] Table 3 shows an example workflow description that includes multiple descriptors.

[0077] [Table 3]

[0078] Note that the additional constraints defined in the table above can be used as baseline rules for validating the semantics of a WDD.

[0079] Similarly, the WD defined above may be presented in JSON format. Table 4 below shows an example of a JSON WD schema.

[0080] [Table 4]

[0081] As shown in Tables 3 and 4, a WDD can contain multiple descriptors, including required descriptors such as general, input, output, processing, and requirements. There are also other optional descriptors such as processing, requirements, configuration, steps, client assistant, etc.

[0082] The WD schema defined above in JSON format can be used as a baseline schema for validating WDD schemas.

[0083] Table 5 shows an example task description that includes multiple descriptors.

[0084] [Table 5]

[0085] Note that the additional constraints defined in the table above can be used as baseline rules for validating the semantics of TDD.

[0086] The TD defined above may be presented in JSON format. Table 6 below shows an example TDD schema in JSON.

[0087] [Table 6]

[0088] The TD schema defined above in JSON format can be used as a baseline schema for validating TDD schemas.

[0089] Table 7 shows an example MPE capability description (MD) that includes multiple descriptors.

[0090] [Table 7]

[0091] Note that the additional constraints defined in the table above can be used as baseline rules for validating the semantics of the MDD.

[0092] The above MD may be expressed in JSON format. Table 8 below shows an example MDD schema in JSON.

[0093] [Table 8]

[0094] The MD schema defined above in JSON format can be used as a baseline schema for validating MDD schemas.

[0095] In this disclosure, the JSON format is used for illustrative purposes only: other formats can also be used for the description document, including but not limited to Extensible Markup Language (XML).

[0096] It should be noted that the WDD, TDD, FDD, and MDD schemas are for illustrative purposes only. These schemas can serve as basic NBMP schemas, but further constraints can be added to these schemas, for example based on actual design requirements, to form corresponding derived schemas. The derived schemas can also include any schemas that are variations of the basic NBMP schemas. In some example implementations, both the basic NBMP schemas and the derived NBMP schemas can serve as baseline NBMP schemas for validating corresponding description documents. It should be noted that the description documents may be instantiations of specific schemas.

[0097] In some example implementations, the NBMP schema defined in ISO / IEC 23090-8 (a standard for network-based media processing) can be used as the base NBMP schema.

[0098] Descriptors included in the above-mentioned description documents (eg, WDD, TDD, FDD, and MDD) may be presented in, for example, JSON format.

[0099] Table 9 shows an example of a scheme descriptor schema. A scheme descriptor document can be written that is based on (i.e., instantiated from) the corresponding scheme descriptor schema.

[0100] [Table 9]

[0101] Table 10 shows an example of a startup delay descriptor schema. A startup delay descriptor document can be written based on the corresponding startup delay descriptor schema.

[0102] [Table 10]

[0103] Table 11 shows an example client assistance descriptor schema.

[0104] [Table 11]

[0105] Many other descriptors may be defined and used in the NBMP, which may include, but are not limited to, general descriptors, input descriptors, output descriptors, processing descriptors, requirements descriptors, configuration descriptors, failover descriptors, event descriptors, variable descriptors, monitoring descriptors, reporting descriptors, notification descriptors, assertion descriptors, request descriptors, authorization descriptors, repository descriptors, security descriptors, step descriptors, function descriptors, scale descriptors, schedule descriptors, etc. A descriptor document may be written or presented based on its corresponding descriptor schema, for example in JSON format.

[0106] The NBMP system may communicate between entities connected via a network for media processing using interfaces including data formats and application program interfaces (APIs). The APIs may include, for example, the following APIs: · NBMP Workflow API, used by NBMP sources to create and control media processing workflows. · An NBMP Feature Discovery API that provides a means for a workflow manager and / or NBMP source to discover media processing features that can be loaded as part of a media processing workflow. · NBMP Task API used by the Workflow Manager to configure and monitor tasks at runtime. ·NBMP MPE API used by the Workflow Manager to look up MPE functions.

[0107] Each API may include the following aspects: an API operation, an API request, and an API response.

[0108] The Workflow API is used by an NBMP source (or NBMP client) to manage workflows through a Workflow Manager. The Workflow Manager can support the Workflow API operations shown in Table 12.

[0109] [Table 12A] [Table 12B] [Table 12C]

[0110] The workflow manager uses task API operations to configure and control tasks. Table 13 shows example task API operations.

[0111] [Table 13A] [Table 13B] [Table 13C]

[0112] The Feature Discovery API is used by the Workflow Manager and NBMP Sources to discover NBMP features supported by the NBMP Platform. Referring to Figure 3, these features can be cataloged in a feature repository using NBMP Feature Descriptions (FDs).

[0113] A discovery query can be used to discover one or more features in a feature repository by the properties described in the query. A query string is used to describe these properties.

[0114] In some example implementations, a query string that conforms to IETF RFC 3986:2005, section 3.4 may be used. The query string may contain a set of key-value pairs separated by a single "&" character. In each key-value pair, the key and value shall be separated by a single "=" character. Wildcard expressions may be used in the query string. For example, "*" may be used to match zero or more characters, "^" may be used to match the beginning of a value, and "$" may be used to match the end of a value.

[0115] Table 14 shows example feature discovery API operations.

[0116] [Table 14]

[0117] The MPE API defines an interface for retrieval of MPE functionality by a workflow manager. Table 15 shows example MPE API operations.

[0118] [Table 15]

[0119] In an NBMP system, entities such as a workflow manager entity, a task entity, a functional repository entity, and an MPE entity must meet certain requirements, which are described below.

[0120] In an example implementation, the workflow manager may need to support the following API aspects: Workflow API action responses; Task API actions; Feature discovery API behavior; and MPE API Operation

[0121] When a request for media processing arrives from an NBMP source (or NBMP client) for which a connection map is not provided, the workflow manager uses the feature discovery API to design one or more workflow options using the features in the feature repository, and then instantiates the workflow based on the given preferences. If a request from an NBMP client includes a workflow with a connection map and associated features, the workflow manager can use the feature discovery API to request the feature description in order to instantiate the workflow.

[0122] Once a list of tasks that need to be included in a workflow has been compiled, the workflow manager can connect those tasks to prepare the required workflow.

[0123] If the workflow manager is unable to create a workflow or access a function, it provides a response to the NBMP service reflecting a failure to create the workflow.

[0124] The workflow manager can support the following transitions in the state of a workflow: · onInstantiation - when a CreateWorkflow action is received, "state" is set to the value "instantiated". · onInstantiation, upon receiving a RetrieveWorkflow action, sets the "state" to "instantiated" and, in case of a previously configured workflow, transitions it to the instantiated state. · When onWorkflowConfig receives an UpdateWorkflow action, its "state" is set to "idle" and it transitions to the idle state while in the instantiated state. · onInstantiation followed by onWorkflowConfig, upon receiving a CreateWorkflow action, the "state" is set to "idle" and transitions it to the instantiation state and then to the idle state. onTermination, when a DeleteWorkflow action is received. · onReset, when it receives an UpdateWorkflow action, the "state" is set to "instantiating" while in the idle state and transitions it to the instantiating state. onErrorHandling, when an UpdateWorkflow is received while in an error state. · onStart transitions the state from idle to running when media data or metadata starts arriving. onStop SHALL transition the state from Running to Idle when all media data or metadata has stopped arriving (by observing all input timeout values ​​and completing processing of any received input). · onCompletion shall transition the state from running to idle once processing is completed (by observing the timeout values ​​for all inputs and completing processing of received inputs). · OnError transitions the state from Running to Error state if an error occurs.

[0125] The workflow manager instantiates tasks that conform to the task groups defined in the workflow description.

[0126] In an exemplary implementation, the feature repository shall support the following API aspects: Feature discovery API actions require.

[0127] The feature repository may store entries for features and feature groups.

[0128] The feature repository SHALL support queries using the query string format, e.g., as described above. If there are multiple key-value pairs included in the query string, the feature repository SHALL return all feature descriptions that match each value of the key-value pairs in the query string.

[0129] The feature repository SHALL support basic wildcard searching: for an existing wildcard in a value, the feature repository SHALL return features that have one or more properties that partially match the non-wildcard portion of the corresponding value.

[0130] In an exemplary implementation, the task entity shall support the following API aspects: Task API operation response.

[0131] A task shall support the following transitions between its states: -onInstantiation - When a CreateTask action is received, the "state" is set to "instantiated". · When onTaskConfiguration receives an UpdateTask operation, the "state" is set to "idle". · onInstantiation followed by onTaskConfiguration sets the "state" to "idle" when a CreateTask operation is received. onTermination, when a DeleteTask action is received. -onReset sets the "state" to "instantiated" when an UpdateTask action is received. onErrorHandling: When an UpdateTask is received while in an error state. · onStart: When media data or metadata starts arriving, the task transitions its state from the idle state to the running state. · onStop, when all media data or metadata stops arriving (by observing all input timeout values ​​and completing the processing of received input), the task transitions from the running state to the idle state. · onCompletion: When processing is completed (by observing the timeout values ​​for all inputs and completing processing of received inputs), the task transitions its state from running to idle. · OnError, when an error occurs, the task must transition from the Running state to the Error state.

[0132] The lifecycle of a workflow relates to the lifecycle of its tasks as follows: If a workflow is in the instantiated state, all its tasks shall be in the instantiated state. When a workflow is in the idle state, all its tasks are assumed to be in the idle state. If one or more tasks in a workflow are in an error state, the workflow shall transition to an error state. When a workflow is destroyed, all its tasks shall transition to the destroyed state.

[0133] The MPE shall support the following API aspects: MPE API operation response

[0134] In an NBMP system, description documents may generally include WDD, TDD, FDD, and MDD, which may be instantiations from corresponding schemas. These description documents may be further based on lower level support documents such as NBMP Descriptor Schema documents, NBMP Descriptor Parameter documents (used to define NBMP parameters). These documents may be released by a single vendor or by multiple vendors. Alternatively, these documents may cover various releases and have different versions. Due to the large number of description documents (and their support documents) required to support NBMP media flows, it is important to ensure that all these description documents, whether within the same vendor or from different vendors, conform to the NBMP standard, both syntactically and semantically. Non-conformance in any one of these description documents may result in degradation, interruption, or even unexpected termination of media services, which severely impacts the user experience. Non-conformance of description documents may also add operational, maintenance, and / or troubleshooting costs to vendors and / or operators. For example, significant time and effort is required to identify which documents are non-conforming. It is therefore beneficial to perform certain pre-checks on these documents to ensure their conformance. A pre-check or pre-validation can validate these documents syntactically and semantically.

[0135] This disclosure describes various embodiments for verifying / checking NBMP documents and checking conformance of NBMP entities.

[0136] Referring to Figure 4, in one embodiment, a two-stage validation process is introduced. As shown in Figure 4, the validation process can use a schema validator 402 and a semantic validator 404 (these two validators are commonly referred to as NBMP validators). These two validators can be arranged in a serial fashion.

[0137] The input documents to the validation process may include any description documents, such as WDD, TDD, FDD, and MDD. As mentioned above, each description document may include at least one descriptor. The input documents may also include any descriptor documents, for example, descriptor documents written or presented in JSON format.

[0138] As shown in FIG. 4, the verification process involves two steps, which are described below.

[0139] Step 1 - Schema Validation The input document is validated by the schema validator 402 based on the NBMP schema that corresponds to the input document.

[0140] As one example, if the input document is a description document such as a WDD, a WDD baseline schema may be selected and referenced by the schema validator. As another example, if the input document is a descriptor document such as a scheme descriptor document, a scheme descriptor schema may be selected and referenced by the schema validator.

[0141] In some example implementations, the basic NBMP schema may be used as a baseline schema.

[0142] In some example implementations, a derived NBMP schema based on the base NBMP schema can be used as a baseline schema. As mentioned above, the derived NBMP schema can include additional constraints and / or descriptors.

[0143] In some example implementations, the schema validator can include additional schema files (e.g., lower-level schema files) when performing validation on an input file. For example, a description document can include multiple descriptors. To validate each descriptor, the schema validator can pull in or read a descriptor schema that corresponds to each descriptor.

[0144] In this step, the schema of the input document is verified, e.g., whether the input document contains all the required descriptors; whether there are unknown elements such as descriptors in the input document;

[0145] Step 2 - Semantic Verification In this step, the semantics of the input document is verified.

[0146] Additional constraints can be imposed on description documents as defined in the "Additional Constraints" column, as shown in Tables 1, 3, 5, and 7. These constraints can be applied at the descriptor level and can include additional requirements such as: one or more parameters should not be present in a descriptor; one or more parameters must be present in a descriptor; preconditions / triggers based on a descriptor to include or exclude certain parameters in the same descriptor; preconditions / triggers based on one descriptor to include or exclude certain parameters in different descriptors; a descriptor within a description document should have additional objects if the precondition is met; further restrictions must be imposed on a descriptor such as a description document.

[0147] In some example implementations, the semantic verifier can compile a set of rule tables, each table including additional constraints for a particular description definition table. For example, the set of rule tables can include a WDD rule table, a TDD rule table, an FDD rule table, and an MDD rule table. For example, each row of the table can represent a constraint.

[0148] In some example implementations, the above rule tables can be applied at the descriptor level, i.e., each descriptor can have a corresponding rule table that contains additional constraints.

[0149] In this step, an input document, such as a description file (eg, WDD, TDD, FDD, MDD) or a descriptor file, has its semantics verified based on, for example, a set of rule tables.

[0150] As an example, a TDD has a "processing" descriptor. Additional constraints are imposed on this descriptor: "The following parameters shall not be present: keywords; functional constraints; connection maps" (see Table 5). Therefore, based on the rule table for the TDD, the semantics of the input TDD is checked to ensure that such parameters are not present. Alternatively, the rule table may be compiled at the descriptor level. In this case, the semantic verifier can use the corresponding descriptor rule table as a baseline. In this example, the table would be the "processing" descriptor rule table.

[0151] Thus, in this step, the semantics of the input document can be verified by using a set of rule tables.

[0152] Each of step 1 and step 2 can generate a validation report showing the validation results. In case of validation failure, a failure code and / or detailed failure reason can be recorded in the validation report. A combined report showing the validation results of both step 1 and step 2 can also be generated.

[0153] In some example implementations, a web interface, or web service 406, may be provided by the NBMP validator. Input documents may be validated by accessing the NBMP validator via the web service.

[0154] In an NBMP system, media services may be provided by different vendors. Each vendor may implement its own NBMP entities, such as a workflow manager entity, a media processing entity, a task entity, and a capability repository entity. Entities belonging to different vendors may need to interoperate with each other. Incompatibility of entities may add operational, maintenance, and / or troubleshooting costs to vendors and / or operators. For example, identifying which entities are not compliant may require significant time and effort. To ensure smooth media streaming services, it is important that each of these entities conforms to the NBMP standard. This disclosure describes various embodiments for an NBMP entity validator to validate the conformance of NBMP entities. Conformance may cover various aspects including APIs; state transitions; event / task / workflow monitoring, reporting, and notification; and interactions between these entities.

[0155] Figures 5a-5d show examples of NBMP entity validators. Each of these validators interacts with an NBMP entity and is used to test / verify the conformance of the NBMP entity. Conformance testing can be performed from different perspectives, as will be explained in more detail below.

[0156] In some example implementations, API operations such as create, update, search, and delete operations for each API are tested. For example,

[0157] For the Workflow API, the following operations are tested: CreateWorkflow, UpdateWorkflow, DeleteWorkflow, and RetrieveWorkflow.

[0158] For the Task API, the following operations are tested: CreateTask, UpdateTask, GetTask, and DeleteTask.

[0159] For the function discovery API, the following operations are tested: DiscoverFunctions, DiscoverFunctionsInGroup, and DiscoverGroupsOfFunction.

[0160] For the MPE API, the following operations are tested: RetrieveCapabilities and UpdateMPE.

[0161] In some example implementations, the monitoring, reporting, and notification functions of an NBMP entity are tested by an NBMP entity verifier.

[0162] Referring to Fig. 5b, the NBMP entity verifier may receive reports and / or notifications from the MPE entity. The NBMP entity verifier may further check the sanity of the received reports and / or notifications.

[0163] 5c, the NBMP entity validator may receive reports and / or notifications from the task entity. The NBMP entity validator may further check the sanity of the received reports and / or notifications.

[0164] 5d, the NBMP entity validator may receive reports and / or notifications from the workflow manager entity. The NBMP entity validator may further check the sanity of the received reports and / or notifications.

[0165] In some example implementations, as shown in Figure 5c, the NBMP entity validator can obtain input from a task configuration file that contains the configuration of one or more tasks. For each task, the NBMP entity validator can use its corresponding configuration (obtained from the task configuration file) to drive the task API (e.g., use the configuration to form API function call parameters).

[0166] The NBMP entity validator may configure the Monitor, Reporting, and / or Notification descriptors via the task API. When a report / notification is received, the validator may further verify whether the report / notification matches the corresponding configuration provided to the task entity.

[0167] For example, a report descriptor can consist of parameters for event, variable, system event, system variable, report type, report interval, report start time, URL, and delivery method. An NBMP entity validator can verify that a received report conforms to these parameters. For example, the report type should match the "report type" parameter, and the report interval should match the "report interval" parameter.

[0168] In another example, a notification descriptor may include the following parameters: event, variable, system event, system variable, notification time, severity, notification type, URL, notification interval, and the NBMP entity validator can verify that the received report conforms to these parameters.

[0169] In some example implementations, the NBMP entity validator can validate the state transition behavior of various NBMP entities, for example, as described in the previous section, a workflow manager must support workflow state transitions, and a task entity must support task state transitions.

[0170] In some example implementations, the state transitions may be driven by an NBMP entity validator, for example, via an API call to the NBMP entity, i.e., the NBMP entity validator can invoke an API call to trigger a state transition, or a series of state transitions.

[0171] In some example implementations, the NBMP entity verifier can simulate multiple entities and can further simulate the NBMP source. Thus, an end-to-end service can be simulated and related NBMP entities can be tested. For example, the NBMP entity verifier can start an NBMP service using the simulated NBMP source. This triggers interactions between the workflow manager and the capability repository, tasks, and MPE. As shown in FIG. 5d, the workflow manager can interact with the NBMP entity verifier (or each simulated NBMP entity in the NBMP entity verifier) ​​via API calls including workflow APIs, task APIs, capability repository APIs, and MPE APIs. The NBMP entity verifier can also modify or delete NBMP services that also trigger corresponding interactions. Interactions between the workflow manager and other NBMP entities, such as task entities, capability repository entities, and MPE entities. The NBMP entity verifier can verify interactions that comply with NBMP requirements.

[0172] In some example implementations, the Workflow Manager implementation may not support all APIs defined in the NBMP standard. In those cases, the conformance tests are limited to those that are defined. For example, if the implementation only supports the Workflow API, the tests are limited to the Workflow API.

[0173] In some example implementations, the validation tests performed by the NBMP entity verifier can include a set of test cases, where each test case tests one or more aspects of the API, functional requirements, or state machine of the entity under test. For each test case, one or more documents (e.g., description documents) need to be created, and the verifier needs to run the tests using those documents as input. The verifier can receive notifications and reports from the entities and match them with the correct results for each test case.

[0174] FIG. 6 illustrates an exemplary method 600 for validating a network-based media processing (NBMP) entity in an NBMP system, the method being performed by an NBMP entity verifier executing on at least one processor, and the method 600 may include some or all of the following steps: step 610 of invoking an application programming interface (API) corresponding to an API operation supported by the NBMP entity, where the API operation is related to at least one of a create operation, an update operation, a search operation, or a delete operation; step 620 of receiving a response from the NBMP entity; and step 630 of determining, based on the response, whether the NBMP entity passes an API test corresponding to the API operation.

[0175] In the present disclosure, a method for validating a network-based media processing (NBMP) document in an NBMP system is disclosed. Executed by an NBMP document validator running on at least one processor, the method includes the steps of obtaining an NBMP document, the NBMP document including at least one of a description document or a descriptor document, selecting a baseline schema and baseline rules based on the NBMP document, validating a schema of the NBMP document based on the baseline schema, validating a semantic of the NBMP document based on the baseline rules, and determining whether the NBMP document complies with the NBMP standard based on a result of validating the schema and semantic of the NBMP document.

[0176] In the above method, the NBMP document is presented in at least one of the following formats: JavaScript Object Notation (JSON) format, or Extensible Markup Language (XML) format.

[0177] In the above method, the description document includes at least one of a workflow description document (WDD); a task description document (TDD); a functional description document (FDD); or an MPE functional description document (MDD), and the descriptor document includes a document corresponding to a descriptor in the description document.

[0178] In the above method, the step of selecting a baseline schema and baseline rules based on the NBMP document may include the steps of: in response to the description document being a WDD, selecting a WDD baseline schema as defined in the NBMP system; in response to the description document being the TDD, selecting a TDD baseline schema as defined in the NBMP system; in response to the description document being an FDD, selecting an FDD baseline schema as defined in the NBMP system; and in response to the description document being an MDD, selecting an MDD baseline schema as defined in the NBMP system.

[0179] In the above method, the baseline rules can be compiled based on additional constraints imposed on at least one descriptor in the NBMP document.

[0180] In the above method, the additional constraints imposed on at least one of the descriptors are: The parameter should not be present in at least one of the descriptors, A parameter must be present in at least one descriptor, additional restrictions on the parameters in said at least one descriptor; or If the prerequisites are met, at least one descriptor or another in the NBMP document should have additional objects. may include at least one of the following:

[0181] The embodiments of the present disclosure may be used separately or combined in any order. Furthermore, each of the methods (or embodiments) may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, the one or more processors execute a program stored on a non-transitory computer-readable medium. In addition to the NBMP, the embodiments of the present disclosure may be applied to other types of media processing technologies / standards.

[0182] The techniques described above may be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media. For example, FIG. 7 illustrates a computer system (1800) suitable for implementing certain embodiments of the disclosed subject matter.

[0183] The computer software may be coded using any suitable machine or computer language that can be assembled, compiled, linked, or similar mechanisms to produce code including instructions that can be executed by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc., directly, or via interpretation, microcode execution, etc.

[0184] The instructions may be executed on various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smart phones, gaming devices, Internet of Things devices, and the like.

[0185] 7 for the computer system (1800) are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing the embodiments of the present disclosure, nor should the arrangement of components be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary embodiment of the computer system (1800).

[0186] The computer system (1800) may include several human interface input devices. Such human interface input devices may be responsive to input by one or more human users through, for example, tactile input (keystrokes, swipes, data glove movements, etc.), audio input (voice, clapping, etc.), visual input (gestures, etc.), and olfactory input (not shown). Human interface devices may also be used to capture certain media that are not necessarily directly associated with conscious human input, such as audio (such as voice, music, ambient sounds, etc.), images (such as scanned images, photographic images obtained from a still camera, etc.), and video (such as two-dimensional video, three-dimensional video including stereoscopic video, etc.).

[0187] The input human interface devices may include one or more of a keyboard (1801), a mouse (1802), a trackpad (1803), a touch screen (1810), a data glove (not shown), a joystick (1805), a microphone (1806), a scanner (1807), and a camera (1808) (only one of each is shown).

[0188] Additionally, the computer system (1800) may include several human interface output devices. Such human interface output devices may stimulate one or more of the human user's senses, for example, through haptic output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touch screen (1810), data gloves (not shown), or joystick (1805), although there may also be haptic feedback devices that do not function as input devices), audio output devices (speakers (1809), headphones (not shown), etc.), visual output devices (such as screens (1810) including CRT, LCD, plasma, or OLED screens, each of which may or may not have touch screen input capability, each of which may or may not have haptic feedback capability, some of which may be capable of outputting two-dimensional visual output, or output in more than three dimensions by means of stereoscopic graphic output, virtual reality glasses (not shown), holographic displays, or smoke tanks (not shown), etc.), and printers (not shown).

[0189] The computer system (1800) may also include human-accessible storage devices and their associated media, such as optical media (1821), including CD / DVD ROM / RW (1820) using CD / DVD or similar media, thumb drives (1822), removable hard drives or solid state drives (1823), legacy magnetic media such as tapes and floppy disks (not shown), specialized ROM / ASIC / PLD based devices (not shown) such as security dongles, and the like.

[0190] Those skilled in the art should also understand that the term "computer-readable medium" as used in connection with the presently disclosed subject matter does not encompass transmission media, carrier waves, or other transitory signals.

[0191] The computer system (1800) may also include an interface (1854) to one or more communication networks (1855). The network may be, for example, a wireless network, a wired network, or an optical network. The network may further be local, wide area, metropolitan, vehicular and industrial, real-time, delay tolerant, etc. Examples of networks include local area networks such as Ethernet, cellular networks including WLAN, GSM, 3G, 4G, 5G, LTE, etc., television wired or wireless wide area digital networks including cable television, satellite television, and terrestrial television, vehicular and industrial including CAN bus, etc. Some networks require an external network interface adapter that is typically attached to some general purpose data port or peripheral bus (1849) (e.g., a USB port of the computer system (1800)), while other networks are typically built into the core of the computer system (1800) by attaching to the system bus as described below (e.g., an Ethernet interface for a PC computer system or a cellular network interface for a smartphone computer system). Any of these networks may be used by the computer system (1800) to communicate with other entities. Such communications may be one-way receive-only (e.g., television broadcast), one-way transmit-only (e.g., from the CANbus to a particular CANbus device), or bidirectional, for example, to other computer systems using local or wide area digital networks. Specific protocols and protocol stacks may be used with each of these networks and network interfaces described above.

[0192] The aforementioned human interface devices, human accessible storage devices, and network interfaces may be attached to a core (1840) of the computer system (1800).

[0193] The cores (1840) may include one or more central processing units (CPUs) (1841), graphics processing units (GPUs) (1842), specialized programmable processing units in the form of field programmable gate areas (FPGAs) (1843), hardware accelerators for specific tasks (1844), graphics adapters (1850), and the like. These devices may be connected via a system bus (1848), along with read-only memory (ROM) (1845), random access memory (1846), and internal mass storage (1847) such as internal hard drives and SSDs that are not accessible to the user. In some computer systems, the system bus (1848) may be accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, and the like. Peripheral devices may be attached directly to the core's system bus (1848) or via a peripheral bus (1849). In one example, a screen (1810) may be connected to the graphics adapter (1850). Architectures for peripheral buses include PCI, USB, etc.

[0194] The CPU (1841), GPU (1842), FPGA (1843), and accelerator (1844) may execute a number of instructions that may be constructed in combination as described above as computer code. This computer code may be stored in ROM (1845) or RAM (1846). Permanent data may be stored, for example, in internal mass storage (1847), while transient data may also be stored in RAM (1846). Rapid storage and retrieval of any memory device may be enabled through the use of cache memory, which may be closely associated with one or more of the CPU (1841), GPU (1842), mass storage (1847), ROM (1845), RAM (1846), etc.

[0195] The computer-readable medium can have computer code thereon for performing various computer-implemented operations. The medium and computer code can be those specially designed and constructed for the purposes of the present disclosure, or they can be of the kind well known and available to those skilled in the computer software arts.

[0196] As a non-limiting example, a computer system having the architecture (1800), and in particular the core (1840), can provide functionality as a result of one or more processors (including CPUs, GPUs, FPGAs, accelerators, etc.) executing software embodied in one or more tangible computer-readable media. Such computer-readable media can be media associated with mass storage that can be directly operated by a user, as described above, or even specific storage of the core (1840), such as the core's internal mass storage (1847) or non-transitory storage, such as ROM (1845). Software implementing various embodiments of the present disclosure can be stored in such devices and executed by the core (1840). The computer-readable media can include one or more memory devices or chips, depending on the particular need. The software enables the cores (1840), and in particular the processors (including CPUs, GPUs, FPGAs, etc.) in the cores (1840), to execute certain processes or certain portions of certain processes described herein, including the definition of data structures stored in RAM (1846) and the modification of such data structures according to the processes defined by the software. Additionally or alternatively, the computer system may provide functionality as a result of logic being hardwired or otherwise implemented in circuitry (e.g., accelerators (1844)) that may act in place of or cooperate with the software to execute certain processes or certain portions of certain processes described herein. Where appropriate, references to "software" may encompass logic, and vice versa. References to computer-readable media may encompass circuitry (such as integrated circuits (ICs)) that store software for execution, circuitry that embodies logic for execution, or both, where appropriate. The present disclosure encompasses any appropriate combination of hardware and software.

[0197] 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]

[0198] 100 Environment 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 Device, HTTP status code 201 HTTP status code 202 HTTP status code 210 Bus 220 Processor 230 Memory 240 Memory Components 250 Input Components 260 Output Components 270 Communication Interface 300 NBMP System, NBMP Architecture 310 NBMP Source 311 NBMP Workflow API 312 Feature Discovery API 313 Feature Discovery API 314 API 315 API 316 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 Sink, Media Source 402 Schema Validator 404 Semantic Verifier 406 Web Services 600 ways 1800 Computer Systems 1801 Keyboard 1802 Mouse 1803 Trackpad 1805 Joystick 1806 Mike 1807 Scanner 1808 Camera 1809 Speaker 1810 screen 1821 Optical media 1822 Thumb Drive 1823 Solid State Drive 1840 Core 1841 Central Processing Unit (CPU) 1842 Graphics Processing Unit (GPU) 1843 Field Programmable Gate Area (FPGA) 1844 Hardware Accelerator 1845 Read-Only Memory (ROM) 1846 Random Access Memory 1847 Internal Mass Storage 1848 System Bus 1849 Peripheral Bus 1850 Graphics Adapter 1854 Interface 1855 Communication Network

Claims

1. 1. A method for verifying a network-based media processing (NBMP) entity in an NBMP system, the method being performed by an NBMP entity verifier running on at least one processor, the method comprising: Invoking an application programming interface (API) corresponding to an API operation supported by the NBMP entity, the API operation comprising: Creation action, update operation, A search operation, or Delete Action and receiving a response from the NBMP entity; determining whether the NBMP entity passes an API test corresponding to the API operation based on the response; A method comprising:

2. The NBMP entity comprises: Functional repository entities, Task entities, A workflow manager entity, or Media Processing Entity (MPE) The method of claim 1 , comprising at least one of:

3. Prior to the step of invoking the API corresponding to the API operation supported by the NBMP entity, the method further comprises: retrieving a description document indicating a resource associated with the NBMP entity, the resource comprising: Workflow resources, Task resources, or MPE Functional Resources and formulating API parameters based on the resources; Further comprising: The step of invoking the API comprises: calling the API that corresponds to the API operation supported by the NBMP entity using the API parameters as input parameters for the API. The method of claim 1 or 2, comprising:

4. the response includes at least one of a HyperText Transfer Protocol (HTTP) status code or a response body; determining whether the NBMP entity passes the test corresponding to the API test, determining whether the NBMP entity passes the API test based on the HTTP status code; The method of claim 1 or 2, comprising:

5. Prior to the step of invoking the API corresponding to the API operation supported by the NBMP entity, the method further comprises: retrieving a description document indicating resources associated with the NBMP entity, the description document indicating a descriptor including at least one of a monitor descriptor, a report descriptor, or a notification descriptor; formulating API parameters based on the descriptors; Further comprising: The step of invoking the API comprises: invoking the API corresponding to the API operation supported by the NBMP entity using the API parameters as input parameters for the API. The method of claim 1 or 2, comprising:

6. receiving a report from the NBMP entity in response to the descriptor including the report descriptor, the report being transmitted by the NBMP entity based on the report descriptor; or receiving a notification from the NBMP entity in response to the descriptor including the notification descriptor, the notification being sent by the NBMP entity based on the notification descriptor; The method of claim 5 further comprising:

7. the NBMP entity is a workflow manager entity; The step of invoking the API triggers a workflow state transition configured by the workflow manager entity and triggered by the NBMP entity verifier; The method comprises: Validating the state transitions of the workflow according to workflow lifecycle rules. The method of claim 1 or 2, further comprising:

8. the NBMP entity is a task entity; The step of invoking the API triggers a state transition of a task configured by the task entity and triggered by the NBMP entity verifier; The method comprises: Validating the state transitions of the task according to task lifecycle rules. The method of claim 1 or 2, further comprising:

9. The NBMP entity verifier can simulate an NBMP source, and the method further comprises: triggering a set of actions to be performed by the workflow manager entity, the set of actions including creating a workflow, searching for the workflow, updating the workflow, and deleting the workflow; 3. The method of claim 2, further comprising: validating the workflow manager entities that interact with the NBMP entity validator using at least one of the following APIs as required within the NBMP system: a workflow API, a task API, a function repository API, or an MPE API.

10. 1. A device for hosting an NBMP entity verifier for verifying an NBMP entity in a network-based media processing (NBMP) system, the device comprising: a memory for storing computer instructions; and a processor in communication with the memory, the processor executing the computer instructions causing the device to: Invoke an application programming interface (API) corresponding to an API operation supported by the NBMP entity, the API operation comprising: Creation action, update operation, A search operation, or Delete action, relates to at least one of receiving a response from the NBMP entity; determining whether the NBMP entity passes an API test corresponding to the API operation based on the response; The device is configured to:

11. The NBMP entity comprises: Functional repository entities, Task entities, A workflow manager entity, or Media Processing Entity (MPE), The device of claim 10 , comprising at least one of:

12. Before the processor is configured to cause the device to call the API corresponding to the API operation supported by the NBMP entity, the processor may further cause the device to: retrieving a description document indicating a resource associated with said NBMP entity, said resource being Workflow resources, Task resources, or MPE functional resources, one of Formulating API parameters based on the resources; It is configured as follows: When the processor is configured to cause the device to invoke the API, the processor may cause the device to: Invoking the API corresponding to the API operation supported by the NBMP entity using the API parameters as input parameters of the API.

12. A device as claimed in claim 10 or 11, configured so as to

13. the response includes at least one of a HyperText Transfer Protocol (HTTP) status code or a response body; When the processor is configured to cause the device to determine whether the NBMP entity passes the API test corresponding to the API operation, the processor may cause the device to: determining whether the NBMP entity passes the API test based on the HTTP status code; 12. A device as claimed in claim 10 or 11, configured so as to

14. Before the processor is configured to cause the device to call the API corresponding to the API operation supported by the NBMP entity, the processor may further cause the device to: retrieving a description document indicating resources associated with the NBMP entity, the description document indicating a descriptor including at least one of a monitoring descriptor, a reporting descriptor, or a notification descriptor; Formulating API parameters based on the descriptors; It is configured as follows: When the processor is configured to cause the device to invoke the API, the processor may cause the device to: Invoking the API corresponding to the API operation supported by the NBMP entity using the API parameters as input parameters of the API.

12. A device as claimed in claim 10 or 11, configured so as to

15. When the processor executes the computer instructions, the processor further causes the device to receiving a report from the NBMP entity in response to the descriptor including the report descriptor, the report being transmitted by the NBMP entity based on the report descriptor; receiving a notification from the NBMP entity in response to the descriptor including the notification descriptor, the notification being transmitted by the NBMP entity based on the notification descriptor; The device of claim 14 configured to:

16. the NBMP entity is a workflow manager entity; Invoking the API triggers a workflow state transition configured by the workflow manager entity and triggered by the NBMP entity verifier; When the processor executes the computer instructions, the processor further causes the device to Validating the state transitions of the workflow according to workflow lifecycle rules 12. A device as claimed in claim 10 or 11, configured so as to

17. the NBMP entity is a task entity; Invoking the API triggers a state transition of a task configured by the task entity and triggered by the NBMP entity verifier; When the processor executes the computer instructions, the processor further causes the device to Validating the state transitions of the task according to task lifecycle rules 12. A device as claimed in claim 10 or 11, configured so as to

18. The NBMP entity verifier may simulate an NBMP source, and when the processor executes the computer instructions, the processor may further cause the device to: triggering a set of actions to be performed by the workflow manager entity, the set of actions including creating a workflow, searching for the workflow, updating the workflow, and deleting the workflow; having the Workflow Manager entities interacting with the NBMP entity validator validated using at least one of the following APIs as required by the NBMP system: Workflow API, Task API, Function Repository API, or MPE API; The device of claim 11 configured to:

19. 1. A non-transitory storage medium for storing computer-readable instructions that, when executed by a processor of a device hosting a network-based media processing (NBMP) entity verifier for verifying NBMP entities in an NBMP system, cause the processor to: Invoke an application programming interface (API) corresponding to an API operation supported by the NBMP entity, the API operation comprising: Creation action, update operation, A search operation, or Delete action, relates to at least one of receiving a response from the NBMP entity; determining whether the NBMP entity passes an API test corresponding to the API operation based on the response; Non-transitory storage medium.

20. The NBMP entity comprises: Functional repository entities, Task entities, A workflow manager entity, or Media Processing Entity (MPE) 20. The non-transitory storage medium of claim 19, comprising at least one of:

Images