DeepStream Reference Designs/Customizing the Project/Implementing Custom Media: Difference between revisions

DeepStream Reference Designs/Customizing the Project/Implementing Custom Media (view source)

Revision as of 18:28, 7 July 2022

237 bytes added , 7 July 2022

→‎Media Interface Operations

Felizondo

583

edits

@@ Line 26: / Line 26: @@
 == Media Interface Operations ==
-As shown in the diagram, any custom Inference Parser module must implement the operations that are defined by the interface named "Inference Parser". As a user, you can add more elements to the design of the said component, for example, add new methods, modify the constructor of the class, and even carry out your implementations of each of the operations exposed by the interface. The important thing is that these methods are maintained. Next, there will be a brief explanation of the purpose of each of the operations defined by the Inference Parser interface. Remember that the specific implementation is up to your criteria or needs.
+As shown in the diagram, any custom Media module must implement the operations that are defined by the interface named "Media". As a user, you can add more elements to the design of the said component, for example, add new methods, modify the constructor of the class, and even carry out your implementations of each of the operations exposed by the interface. The important thing is that these methods are maintained. Next, there will be a brief explanation of the purpose of each of the operations defined by the interface. Remember that the specific implementation is up to your criteria or needs.
-* '''start:''' This method is responsible for parsing the information received by the Inference Listener, using a custom format defined by the application. The received inference is a String, and at the end of interpreting said inference, the method must build an Inference Info object that contains the parsed information and return it to the module that invoked it.
+* '''start:''' As its name indicates, the purpose of this method is to initialize the data transmission process coming from the cameras. The idea is that Camera Capture can manage the right times to start receiving information from each Media.
-* '''stop:''' This method is responsible for parsing the information received by the Inference Listener, using a custom format defined by the application. The received inference is a String, and at the end of interpreting said inference, the method must build an Inference Info object that contains the parsed information and return it to the module that invoked it.
+* '''stop:''' Method that represents the counterpart of the start operation. As its name indicates, the idea is that the Camera Capture module can stop the flow of information received by the cameras, through this function. The fact that a Media stops its operation does not mean that it has been eliminated, it is simply in a paused state, which can be reactivated later.
-* '''get_name:''' This method is responsible for parsing the information received by the Inference Listener, using a custom format defined by the application. The received inference is a String, and at the end of interpreting said inference, the method must build an Inference Info object that contains the parsed information and return it to the module that invoked it.
+* '''get_name:''' This is a simple method that allows you to get the name with which a certain instance of Media is created. Other modules or components of the system may require some type of management with the Media, so when obtaining the identifier they can carry out the respective processing tasks.
-* '''get_triggers:''' This method is responsible for parsing the information received by the Inference Listener, using a custom format defined by the application. The received inference is a String, and at the end of interpreting said inference, the method must build an Inference Info object that contains the parsed information and return it to the module that invoked it.
+* '''get_triggers:''' According to the system design, each Media created will have one or more associated triggers, which abstract the business rules of the application and determine the moment necessary to activate a certain action in that specific Media. With this method provided by the interface, it is possible to obtain a list of the triggers associated with each Media.
-* '''register_error_callback:''' This method is responsible for parsing the information received by the Inference Listener, using a custom format defined by the application. The received inference is a String, and at the end of interpreting said inference, the method must build an Inference Info object that contains the parsed information and return it to the module that invoked it.
+* '''register_error_callback:''' Through this function, the Camera Capture module that manages the Media can register a callback function for error handling. The idea is that this callback is in charge of monitoring the flow of information coming from each Media, and being able to carry out actions when an error occurs in the camera system or in the process of obtaining the information. For example, in the APLVR application, the error callback is responsible for restarting the Media instance that reported an error and stopped. What is sought with this type of strategy is that the system can recover automatically in any eventuality, without the need for manual intervention by the user. Of course, the above is just an example of what an implementation of this type of callback could be and the user can implement other types of actions.
 == Supporting a New Camera ==