Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU):Jetson • DeepStream Version:6.0.1 • JetPack Version (valid for Jetson only):4.6.1 • TensorRT Version:8.2.1 • NVIDIA GPU Driver Version (valid for GPU only) • Issue Type( questions, new requirements, bugs):question • How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing) • Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)
Hi,
I am running the python version of the sample program.
As per the README,
“Make a copy of the image, modify it and save to a file”
I have just checked the following,
The first and second images saved are all in black (jpg),
The third and subsequent images were of the rtsp camera image (jpg) that was used as the argument.
Why are the first and second images black (jpg)?
Also, this jpg file has the save time added to the filename that saves the image from the base program.
from ctypes import *
- import time
+ import time, datetime
import sys
・・・
if save_image:
+ now_time = datetime.datetime.fromtimestamp(time.time())
+ img_path = "{}/stream_{}/frame_{}_{}.jpg".format(folder_name, frame_meta.pad_index, frame_number, now_time.strftime('%b_%d_%Y_%I%M%S_%p'))
- img_path = "{}/stream_{}/frame_{}.jpg".format(folder_name, frame_meta.pad_index, frame_number)
cv2.imwrite(img_path, frame_copy)
did every frames show black?
No. Only the frame immediately after startup.
“frame_60_Jan_29_2024_064506_AM.jpg” and later are able to save the video, but "frame_30_Jan_29_2024_064504_AM.jpg " was a black image with bbox lines.
did you modify the code? which code branch are you testing? you can use git branch to check.
are the four screenshots saved frames in tiler_sink_pad_buffer_probe? can you see the normal rendering if using nv3dsink？ is the rendering always normal? wondering if it is dumping jpg bug.
Branch is master and tags are v1.1.1. (Because we are running in DeepStream SDK 6.0.1 environment)
The previous changes to “deepstream_imagedata-multistream.py” in v1.1.1 have been made.
A2:
are the four screenshots saved frames in tiler_sink_pad_buffer_probe?
Yes, the four screenshots are frames saved by tiler_sink_pad_buffer_probe.
The execution is running with only one input of rtsp as follows.
The screenshot is a jpg file saved by “cv2.imwrite(img_path, frame_copy)” in the code.
can you see the normal rendering if using nv3dsink？
Yes, you can see it.
is the rendering always normal?
Yes, it is normal.
However, immediately after the code is executed, it seems that the input video is taking a long time to render in nv3dsink and the input video is accumulating.
(Immediately after execution, there is a difference between the time in the rendered IP camera and the current time, but the difference gradually shrinks.)
wonder if it is dumping jpg bug.
Immediately after execution, do frames accumulate before rendering, and is this affected by rushing to process the accumulated frames?
thanks for the sharing! what is your GPU device model? since 6.0.1 is an old version, can you upgrade the DeepStream version? I can’t reproduce on Orin with DS6.4.
