Hi guys,
I have some question about the hardware decoder of jetson nano.
1- I want a clean code for multi-stream decoding using python code
2- When nano is decoding multi-stream using special decoding hardware, Is also CPU busy for this task? if so, why? Is’t done this process only on hardware decoding?
Hi,
You can run sudo tegrastats to get system status. If you see NVDEC in tegrastats, it is hardware decoding.
We enabl ehardware acceleration in tegra_multimedia_api and gstreamer. If you use gstreamer nvv4l2decoder element in your python code, it is hardware decoding.
1- When I use these below gstreamer elements in opencv, I get some results:
CPU usage 30-45 %, when decoding 8 streaming with 1920x1080 resolution, and I also can decoding 9 streaming with 1920x1080 resolution, but Jetson nano support 8 stream, righ? why this problem can be happend?
Yes, you have that right. A full guide to the accelerated elements can be found at the link below.
I add nvv4l2decoder into the state 1?
According to the documentation, omx decoders are deprecated, so you might want to use nvv4l2decoder anyway.
When nano is decoding multi-stream using special decoding hardware, Is also CPU busy for this task?
No. With CUDA, your gpu can be doing something (even many things), while your CPU does something else entirely. Here are some examples from PyTorch of how it can work.
Thanks.
In the Q3, my mean is that, As you see in my sudo tegrastats, usage of cpu is there, why? whereas I run only python code for multi-stream on hardware decoding. why cpu is busy? Is it common? or that is due to decoding process?
You mean is that I don’t use zero-copy memory method? I do duplicated data in memory? How to correct this problem? If is set appsink as gstream elemet, this problem can be solve?
I use these elements gstreamer in the opencv and the sudo tegrastats result is shown the state 1 above:
For using appsink in OpenCV, this cannot be eliminated. Optimal pipeline on Jetson Nano is to have NVMM bufffers from source to sink. OpenCV is CPU-based stackand it only accepts CPU buffers in appink.
An optimal solution is to leverage CUDA APIs and tegra_multimedia_api. Please refer to
Thanks a lot,
What’s diffrence between usage of video/ x- raw ( memory:NVMM) and video/ x- raw?
Please give me a optimal way of gstream elements for decoding multi-streams using hardware decosing with python appilication.
However if your idea is to modify the buffer (the image itself) within Python, that’s currently not possible. You can modify the metadata (eg. bounding box coordinates of detections, labels, etc), but not the image. It would be very slow in Python.
If you want to use OpenCV within DeepStream, there is an example plugin that does exactly that, however it’s written in c++. You could then use that plugin within Python.
That being said, your plugin will be much faster if you avoid any memory copies and keep the buffer in NVMM, which is GPU memory, so if you do use the example plugin linked above and you know some cuda, you may wish to tear out the OpenCV Mat conversion. As DaneLLL mentions, memory copies are expensive.
Hi
I use omx264dec element in gstreamer, I see NVDEC in tegrastats, that’s mean that nano use hardware decoder, right?
but I don’t know why i use nvv4l2decoder, the decoding is stop, I thinks I have to use another combine of elements for nvv4l2decoder, right?
I run your suggest pipeline, then I get the below logging, but the NVDEC is not shown. and the cpu usage is stucked to zero.
when I use omxh264dec instead of nvv4l2decoder, the NVDEC is shown.
jnano@jnano-desktop:~$ gst-launch-1.0 rtspsrc location=rtsp://192.168.1.101:8554/1920x1080.264 latency=300 ! rtph264depay ! h264parse ! nvv4l2decoder ! nvvidconv ! ‘video/x-raw,format=(string)BGRx’ ! videoconvert ! fakesink
nvbuf_utils: Could not get EGL display connection
Setting pipeline to PAUSED …
Opening in BLOCKING MODE
Pipeline is live and does not need PREROLL …
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://192.168.1.101:8554/1920x1080.264
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (open) Opened Stream
Setting pipeline to PLAYING …
New clock: GstSystemClock
Progress: (request) Sending PLAY request
Progress: (request) Sending PLAY request
Progress: (request) Sent PLAY request
NvMMLiteOpen : Block : BlockType = 261
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 261
nvbuf_utils: Could not get EGL display connection
Setting pipeline to PAUSED …
Opening in BLOCKING MODE
Pipeline is PREROLLING …
ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Internal data stream error.
Additional debug info:
gstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:pipeline0/GstFileSrc:filesrc0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn’t want to preroll.
Setting pipeline to NULL …
Freeing pipeline …