23,794
edits
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 13:54, 31 October 2024
, 31 October 2024no edit summary
No edit summary |
mNo edit summary |
||
| Line 1: | Line 1: | ||
<noinclude> | <noinclude> | ||
{{DeepStream Reference Designs/Head|next=Customizing the Project/Implementing a Custom Application|previous=Customizing the Project/Implementing Custom Actions}} | {{DeepStream Reference Designs/Head|next=Customizing the Project/Implementing a Custom Application|previous=Customizing the Project/Implementing Custom Actions|title=Implementing Custom Media in DeepStream Reference Designs|description=Implementing Custom Media in DeepStream Reference Designs}} | ||
</noinclude> | </noinclude> | ||
| Line 7: | Line 7: | ||
== The Media Module == | == The Media Module == | ||
This element is responsible for encapsulating and managing the information data received through the system's cameras. The main functionality of this component is that it allows the Camera Capture subsystem to carry out a transparent and simple manipulation of the data received, through the operations provided by the Media interface. In addition, the flexibility of the system is increased since the Camera Capture module is not aware of the underlying technology used for processing camera data, so one media can be replaced by another without affecting overall functionality. For example, in the case of the [ | This element is responsible for encapsulating and managing the information data received through the system's cameras. The main functionality of this component is that it allows the Camera Capture subsystem to carry out a transparent and simple manipulation of the data received, through the operations provided by the Media interface. In addition, the flexibility of the system is increased since the Camera Capture module is not aware of the underlying technology used for processing camera data, so one media can be replaced by another without affecting overall functionality. For example, in the case of the [[DeepStream_Reference_Designs/Reference_Designs/Automatic_Parking_Lot_Vehicle_Registration | APLVR reference design]], the Gstd plugin is used to manage media instances. And within the media descriptor, the camera protocol is indicated, which corresponds to RTSP in said system. Other examples of components that could be used for this purpose were mentioned in the [[DeepStream_Reference_Designs/Project_Architecture/High_Level_Design | High-Level Design section]]. | ||
As indicated in other modules of this system, the design of this component is not restricted to a specific implementation, so different technologies, plugins, or your own components can be added within the project structure, however, certain conditions must be respected prior to the incorporation of a custom component. After reading this wiki page, you will know what are the requirements to add your custom Media module to this reference design. | As indicated in other modules of this system, the design of this component is not restricted to a specific implementation, so different technologies, plugins, or your own components can be added within the project structure, however, certain conditions must be respected prior to the incorporation of a custom component. After reading this wiki page, you will know what are the requirements to add your custom Media module to this reference design. | ||
| Line 39: | Line 39: | ||
== Supporting a New Camera == | == Supporting a New Camera == | ||
It is well known that any Media application that involves Computer Vision and AI processing tasks may require the use of different types of cameras that capture the input information to the system. That is why the design of this system provides flexibility in the section that involves selecting the camera type. As previously indicated and shown in the class diagram, each instance of Media created by the Custom Factory uses a Media Descriptor as an input parameter. Using this descriptor it is possible to abstract the camera component used. For example, in the [ | It is well known that any Media application that involves Computer Vision and AI processing tasks may require the use of different types of cameras that capture the input information to the system. That is why the design of this system provides flexibility in the section that involves selecting the camera type. As previously indicated and shown in the class diagram, each instance of Media created by the Custom Factory uses a Media Descriptor as an input parameter. Using this descriptor it is possible to abstract the camera component used. For example, in the [[DeepStream_Reference_Designs/Reference_Designs/Automatic_Parking_Lot_Vehicle_Registration | APLVR Reference Design]], a URL is used as a central component of the descriptor that refers to a camera that transmits via RTSP, which is adapted to the context of a monitoring system in a parking lot with several cameras. This description is used by the GStreamer Daemon plugin (custom component used in APLVR to create Media instances), which creates a GStreamer pipeline that encapsulates the flow of information received. | ||
If you want to support another type of camera, such as receiving information through the "nvarguscamerascr" module with cameras directly connected to the Jetson, it would suffice to modify the Media Descriptor and reuse the custom Media implementation. Of course, we remember that the specific implementations of both the module in charge of abstracting the Media, as well as the type of camera indicated in the descriptor, are left to the user decision who uses this reference design as a basis for other applications. | If you want to support another type of camera, such as receiving information through the "nvarguscamerascr" module with cameras directly connected to the Jetson, it would suffice to modify the Media Descriptor and reuse the custom Media implementation. Of course, we remember that the specific implementations of both the module in charge of abstracting the Media, as well as the type of camera indicated in the descriptor, are left to the user decision who uses this reference design as a basis for other applications. | ||