Tools for Network-Based Media Processing (NBMP) Document and Entity Conformance

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. Non-Provisional Application No. 18 / 301,657, filed April 17, 2023, each of which provisional and non-provisional applications are incorporated herein by reference in their entireties.

[0002] This disclosure relates generally to media streaming technologies, including Network-Based Media Processing (NBMP). More specifically, the disclosed technology includes methods and apparatus for tools to verify and ensure conformance of NBMP documents and entities. [Background technology]

[0003] The Background section of this specification is intended to provide a general background to the disclosure. To the extent described in this Background section, the work of the currently named inventors and other aspects of the description that may not have been prior art at the time of filing this application are not admitted, expressly or implicitly, 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 a time. NBMP shows great potential for improving media processing efficiency, faster and more cost-effective deployment of media services, and the ability to offer 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 offer 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 the steps of obtaining an NBMP document, where the NBMP document includes at least one of a description document or a descriptor document, selecting a baseline schema and baseline rules based on the NBMP document, validating the schema of the NBMP document based on the baseline schema, validating the semantics of the NBMP document based on the baseline rules, and determining whether the NBMP document conforms to the NBMP standard based on results of validating the schema and semantics of the NBMP document.

[0007] Aspects of the present disclosure also provide a method for validating an NBMP entity in a network-based media processing (NBMP) system. The method may be performed by an NBMP entity validator operating on at least one processor and may include calling 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-described method embodiments.

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

[0011] [Figure 1] 1 is a schematic diagram of a communication system in accordance with one or more embodiments of the present disclosure. [Figure 2] 1 illustrates a simplified example of a streaming environment in accordance with one or more embodiments of the present disclosure. [Figure 3] FIG. 1 illustrates a block diagram of an NBMP system in accordance with one or more embodiments of the present disclosure. [Figure 4] An example of an NBMP schema validator and an example of an NBMP semantic validator are shown below. [Figure 5a] An example of an NBMP entity validator is shown below. [Figure 5b] An example of an NBMP entity validator is shown below. [Figure 5c] An example of an NBMP entity validator is shown below. [Figure 5d] An example of an NBMP entity validator is shown below. [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 INVENTION

[0012] 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 FIG. 1, environment 100 may include a user device 110, a platform 120, and a network 130. The devices in 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 embodiments, platform 120 may include a cloud server or a group of cloud servers. In some embodiments, 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 describe platform 120 as being provided 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 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.

[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] Application 124-1 includes 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 for a software application to be installed on user device 110 and run 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 or receive information to one or more other applications 124-1 via virtual machine 124-2.

[0020] Virtual machine 124-2 includes 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 the application and the degree to which 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, virtual machine 124-2 may run on behalf of a user (e.g., user device 110) and manage the infrastructure of 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 resource 124. In some embodiments, with respect to 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, allowing access to the storage system whether it is physical storage or a heterogeneous structure. Separation allows storage system administrators greater flexibility in how they manage storage for end users. File virtualization removes the dependency between data being accessed at a specific file level and where the file is physically stored. This may enable 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 different 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., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, etc., and / or combinations 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 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) in environment 100 may perform one or more functions described as being performed by another set of devices in 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] Bus 210 includes components that enable communication between components of device 200. Processor 220 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 220 may be a central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field programmable gate array (FPGA), application specific integrated circuit (ASIC), or another type of processor. In some embodiments, processor 220 includes one or more processors that can be programmed to perform functions. 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 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, a cartridge, a 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, fewer, different, or differently arranged elements 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.

[0033] For ease of explanation, this disclosure employs terms and names defined in NBMP system-related standards, but this 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 functionality, 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 sent to a media processing entity in the NBMP system.

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

[0039] Media Source: An 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 within 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

[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 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 description details, requirements, and configuration information.

[0050] Workflow Description: A description of media processing details, such as input and output description details, requested media processing, and workflow requirements.

[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 capability 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 capability 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 memory storing code configured to cause the at least one or more processors to perform the functions of the NBMP source 310, the NBMP workflow manager 320, the capability repository 330, the MPE 340, the media source 360, and the media sink 360, respectively.

[0052] The NBMP source 310 can communicate workflow descriptions with the NBMP workflow manager 320 via the NBMP workflow API 311. The NBMP source 310 can also communicate feature descriptions 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 and 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 the feature discovery API 312, which can be the same or a different API from the feature discovery API 313, and can communicate with one or more of the MPEs 340 via API 314 (e.g., an MPE API).

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

[0054] A 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 can 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, communication between the NBMP source 310, the NBMP workflow manager 320, the capability repository 330, and the MPEs 340 may be considered a control flow.

[0055] Each task 341 may include a media processing function 343 and a configuration 342 for the media processing function 343. The tasks 341 within 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 function repository 330 via the function 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 in parallel between the media source 350 and the media sink 360.

[0056] Media source 350 may include memory for storing 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, and one or more MPEs 340 may send the 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 the 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 produce at least one output. A link connecting one node to another in the graph represents transmitting 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] An 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] An NBMP logical item may contain 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), Functional Description Document (FDD), and MPE Functional 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) can be, for example, WDDs, TDDs, FDDs, and MDDs, respectively, each having a valid URL. These resources can 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 feature repository 330 and the workflow manager 320, or between the feature 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 predetermined format, such as JSON format. Similarly, each descriptor may be described and presented in a document that conforms to the predetermined format, such as JSON format.

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

[0069] Table 1 shows an example function 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 the 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 contain multiple descriptors, including required descriptors such as general descriptor, input descriptor, and output descriptor. There may also be other optional descriptors such as processing, requirements, configuration, steps, client-assistant, etc. Note that whether a descriptor is defined as required or optional is for illustrative purposes only. Based on design requirements, a schema may contain 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 descriptors are provided below.

[0075] The JSON format FD schema 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, and client assistant.

[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 to validate 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 exemplary 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, and 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. Derived schemas can also include any schemas that are variations of the basic NBMP schemas. In some exemplary implementations, both the basic NBMP schema and the derived NBMP schemas can serve as baseline NBMP schemas for validating corresponding description documents. It should be noted that description documents may be instantiations of specific schemas.

[0097] In some example implementations, the NBMP schema defined in ISO / IEC 23090-8 (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 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 exemplary client assistance descriptor schema.

[0104] [Table 11]

[0105] Many other descriptors may be defined and used in the NBMP, including, but 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 in, for example, JSON format, based on its corresponding descriptor schema.

[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 capabilities.

[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 the NBMP Source 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, "*" can be used to match zero or more characters, "^" can be used to match the beginning of a value, and "$" can 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 functions by a workflow manager. Table 15 shows example MPE API operations.

[0118] [Table 15]

[0119] In an NBMP system, entities such as the workflow manager entity, task entity, capability repository entity, and 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 operation response; Task API behavior; Feature discovery API behavior; and MPE API operations

[0121] When a request for media processing arrives from an NBMP source (or NBMP client) for which a connectivity 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 connectivity map and associated features, the workflow manager can use the feature discovery API to request the feature descriptions in order to instantiate the workflow.

[0122] Once the 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 it receives the CreateWorkflow action, the "state" is set to the value "instantiated". · onInstantiation, upon receiving a RetrieveWorkflow action, sets the "state" to "instantiated" and, in the case of a previously configured workflow, transitions it to the instantiated state. · When onWorkflowConfig receives an UpdateWorkflow operation, its "state" is set to "idle" and it transitions to the idle state while in the instantiated state. · onInstantiation followed by onWorkflowConfig, when it receives a CreateWorkflow action, the "state" is set to "idle" and it transitions to the instantiation state and then the idle state. onTermination, when a DeleteWorkflow action is received. · onReset, when it receives an UpdateWorkflow action, its "state" is set to "instantiating" while in the idle state, and it 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 received input). onCompletion shall transition the state from running to idle once processing is complete (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 behavior requests.

[0127] The feature repository shall be capable of storing entries for features and feature groups.

[0128] The feature repository MUST 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 MUST return all feature descriptions that match each value of the key-value pairs in the query string.

[0129] The feature repository MUST support basic wildcard searching: for an existing wildcard in a value, the feature repository MUST 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 receives the CreateTask action and sets the "state" to "instantiated". When onTaskConfiguration receives an UpdateTask operation, the "state" is set to "idle". · onInstantiation and the subsequent onTaskConfiguration will set the "state" to "idle" when they receive a CreateTask operation. onTermination, when a DeleteTask action is received. · onReset sets the "state" to "instantiated" when it receives an UpdateTask action. 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 idle to running. onStop: A task transitions from the running state to the idle state when all media data or metadata stops arriving (by observing all input timeout values ​​and completing processing of received input). onCompletion: When processing is completed (by observing all input timeout values ​​and completing processing of received input), 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 of its tasks shall be in the instantiated state. If a workflow is in the idle state, all its tasks are assumed to be in the idle state. If one or more tasks in the workflow are in an error state, the workflow shall transition to an error state. When a workflow is destroyed, all its tasks are moved to the destroyed state.

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

[0134] In an NBMP system, description documents can generally include WDDs, TDDs, FDDs, and MDDs, which may be instantiations of corresponding schemas. These description documents can further be based on lower-level support documents, such as NBMP Descriptor Schema documents and 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 from the same vendor or different vendors, conform to the NBMP standard, both syntactically and semantically. Non-conformance in any one of these description documents can result in degradation, interruption, or even unexpected termination of media services, which severely impacts the user experience. Non-conformance in description documents can 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-compliant. It is therefore beneficial to perform certain pre-checks on these documents to ensure their conformance. Pre-checks or pre-validations can validate these documents syntactically and semantically.

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

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

[0137] Input documents to the validation process can include any description documents, such as WDDs, TDDs, FDDs, and MDDs. As mentioned above, each description document can include at least one descriptor. Input documents can also include any descriptor documents, for example, descriptor documents written or presented in JSON format.

[0138] As shown in Figure 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 can 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, for example, whether the input document contains all the required descriptors; whether there are any unknown elements such as descriptors in the input document;

[0145] Step 2 - Semantic Validation 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 Table 1, Table 3, Table 5, and Table 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 the descriptor; one or more parameters must be present in the descriptor; prerequisites / triggers based on descriptors to include or exclude specific parameters in the same descriptor; prerequisites / triggers based on one descriptor to include or exclude specific parameters in different descriptors; descriptors within a description document should have additional objects if the prerequisites are met; further restrictions need to be imposed on descriptors such as description documents.

[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 in a table can represent a constraint.

[0148] In some example implementations, the above rule tables may be applied at the descriptor level, i.e., each descriptor may 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. An additional constraint is 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] Step 1 and step 2 can each generate a verification report showing the verification results. In case of verification failure, a failure code and / or detailed failure reason can be recorded in the verification report. A combined report showing the verification results of both step 1 and step 2 can also be generated.

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

[0154] In an NBMP system, media services may be provided by various vendors. Each vendor may implement its own NBMP entities, such as a workflow manager entity, a media processing entity, a task entity, and a function repository entity. Entities belonging to different vendors may need to interoperate with each other. Entity incompatibility may add operational, maintenance, and / or troubleshooting costs to vendors and / or operators. For example, identifying which entities are non-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 verify 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 described in more detail below.

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

[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 Figure 5b, the NBMP entity verifier may receive reports and / or notifications from the MPE entities. 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 descriptor, Reporting descriptor, and / or Notification descriptor via the task API. When a report / notification is received, the validator can further verify whether the report / notification matches the corresponding configuration provided to the task entity.

[0167] For example, a report descriptor can include parameters for an event, a variable, a system event, a system variable, a report type, a report interval, a report start time, a URL, and a 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, and notification interval. An NBMP entity validator can verify that a received report conforms to these parameters.

[0169] In some example implementations, an 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 an 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 exemplary implementations, the NBMP entity verifier can simulate multiple entities and can further simulate an NBMP source. Thus, end-to-end services can be simulated and related NBMP entities can be tested. For example, the NBMP entity verifier can start an NBMP service using a simulated NBMP source. This triggers interactions between the workflow manager and the capability repository, task, and MPE. As shown in FIG. 5d, the workflow manager can interact with the NBMP entity verifier (or each simulated NBMP entity within the NBMP entity verifier) ​​through 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 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 supports only the workflow API, the tests are limited to the workflow API.

[0173] In some example implementations, the validation tests performed by the NBMP entity validator can include a set of test cases, each testing 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) must be created, and the validator must run the tests using those documents as input. The validator can receive notifications and reports from the entity 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] This disclosure discloses a method for validating a network-based media processing (NBMP) document in an NBMP system. Executed by an NBMP document validator running on at least one processor, the method includes the steps of obtaining an NBMP document, where the NBMP document includes at least one of a description document or a descriptor document, selecting a baseline schema and baseline rules based on the NBMP document, validating the schema of the NBMP document based on the baseline schema, validating the semantics of the NBMP document based on the baseline rules, and determining whether the NBMP document conforms to the NBMP standard based on results of validating the schema and semantics 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 function description document (FDD); or an MPE function 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: selecting a WDD baseline schema as defined in the NBMP system in response to the description document being a WDD; selecting a TDD baseline schema as defined in the NBMP system in response to the description document being the TDD; selecting an FDD baseline schema as defined in the NBMP system in response to the description document being an FDD; and selecting an MDD baseline schema as defined in the NBMP system in response to the description document being an MDD.

[0179] In the above method, 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 descriptor are: The parameter should not be present in at least one descriptor, 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 descriptor in the NBMP document should have additional objects. It 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 processing circuitry (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, Figure 7 illustrates a computer system (1800) suitable for implementing certain embodiments of the disclosed subject matter.

[0183] Computer software can be coded using any suitable machine or computer language that can be assembled, compiled, linked, or similar mechanisms to create code containing 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, smartphones, gaming devices, Internet of Things devices, and the like.

[0185] 7 for 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 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 computer system (1800).

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

[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 through, for example, tactile output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touchscreen (1810), data gloves (not shown), or joystick (1805), although haptic feedback devices that do not function as input devices may also be present), audio output devices (speakers (1809), headphones (not shown), etc.), visual output devices (such as screens (1810) including CRT, LCD, plasma, or OLED screens, each with or without touchscreen input capability and each with or without 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 (not shown) such as tape and floppy disks, and specialized ROM / ASIC / PLD-based devices (not shown) such as security dongles.

[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 communications networks 1855. The networks may be, for example, wireless, wired, or optical. The networks may further be local, wide-area, metropolitan, vehicular, 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, satellite, and terrestrial television; and vehicular and industrial networks including CAN bus. Some networks require an external network interface adapter that attaches in a standard manner to some general-purpose data port or peripheral bus 1849 (e.g., a USB port on the computer system 1800); other networks are built into the core of the computer system 1800 in a standard manner 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 communication may be one-way receive-only (e.g., television broadcast), one-way transmit-only (e.g., from the CANbus to a specific CANbus device), or bidirectional, e.g., 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 the 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 arrays (FPGAs) (1843), task-specific hardware accelerators (1844), graphics adapters (1850), etc. 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 user-accessible. 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, etc. 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) can execute several instructions, which may be constructed in combination as described above as computer code. This computer code may be stored in ROM (1845) or RAM (1846). Transient data may also be stored in RAM (1846), while permanent data may be stored, for example, in internal mass storage (1847). 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 may have computer code thereon for performing various computer-implemented operations. The medium and computer code may be those specially designed and constructed for the purposes of the present disclosure, or they may 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 architecture (1800), and in particular 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 directly operable 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 on such devices and executed by the core (1840). The computer-readable media can include one or more memory devices or chips, depending on particular needs. Software enables the cores (1840), and in particular the processors (including CPUs, GPUs, FPGAs, etc.) in the cores (1840), to execute specific processes or specific portions of specific processes described herein, including defining data structures stored in RAM (1846) and modifying such data structures in response to the processes defined by the software. Additionally or alternatively, logic may be hardwired into circuitry (e.g., accelerators (1844)) that can act in place of or cooperate with software to execute specific processes or specific portions of specific processes described herein, or the computer system may provide functionality as a result of logic being otherwise embodied. Where appropriate, references to "software" may encompass logic, and vice versa. References to computer-readable media may encompass circuitry (e.g., integrated circuits (ICs)) that stores 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 processors 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 Validator 406 Web Service 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 behavior, update operation, A search operation, or Delete Behavior and receiving a response from the NBMP entity; determining, based on the response, whether the NBMP entity passes an API test that verifies whether the NBMP entity complies with the API operation; A method comprising:

2. The NBMP entity comprises: Feature 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 calling 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 calling the API includes: calling the API corresponding to the API operation supported by the NBMP entity using the API parameters as input parameters of the API.

3. 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 API test verifying whether it complies with the API operations; determining whether the NBMP entity passes the API test based on the HTTP status code; 3. The method of claim 1 or 2, comprising:

5. Prior to the step of calling 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 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; Further comprising: The step of calling the API includes: calling the API corresponding to the API operation supported by the NBMP entity using the API parameters as input parameters of the API.

3. The method of claim 1 or 2, comprising:

6. receiving a report from the NBMP entity in response to the descriptor containing 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 containing 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; Invoking the API triggers a workflow state transition configured by the workflow manager entity and triggered by the NBMP entity validator; 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 includes: triggering a set of actions to be performed by the workflow manager entity, the set of actions including creating a workflow, retrieving 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 needed within the NBMP system: a workflow API, a task API, a function repository API, or an MPE API.

10. 10. A device that hosts an NBMP entity verifier for verifying NBMP entities 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 configured to cause the device to perform the method of claim 1 when the processor executes the computer instructions.

11. 10. A computer program comprising computer-readable instructions that, when executed by a processor of a device that hosts a network-based media processing (NBMP) entity verifier for verifying NBMP entities in an NBMP system, cause the processor to perform the method of claim 1.

Images