Dynamic resolution jpg image deocode with nvstreammux error

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU)
GPU
• DeepStream Version
6.0
• JetPack Version (valid for Jetson only)
• TensorRT Version
8001
• NVIDIA GPU Driver Version (valid for GPU only)
457.6
• Issue Type( questions, new requirements, bugs)
bugs
• 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)

gst-launch-1.0 multifilesrc location=%d.jpg ! jpegparse ! nvjpegdec ! mux.sink_0 nvstreammux width=1920 height=1080 batch-size=1 name=mux ! fakesink

using the command above. and provide images with different shapes. after a while, the pipeline will corrupt and output below message:
CUDA runtime error 700 cudaErrorIllegalAddress at line 584 in file jdapimin.c.

• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)

1.Did you mean gst-launch-1.0 multifilesrc location=%d.jpg...?
2.Could you help to confirm whether it’s hung on the same image?

Yes. if the group of image didn’t change, it will hang on on the same image. but this image will change if i set ths nvstreammux 'properties of width and height

Could you share your image dataset and update the DeepStream to the latest version?
I test the pipeline with ds6.0 in docker on T4 dgpu, it works properly.

It can’t be right. you can use cv::Mat to random generate pictures which width is between 1920 and 300, height is between 1080 and 300. below is my pipline works on ds6.1.1.
May I ask how many pictures you have tested?
I’m sorry My dataset is privated that can’t be shared. But I have tested pic which random generated, it can also reproduce this problem

Normal yolov5 train or test dataset should works same.

I use the coco dataset. It contains 5000 pictures of different sizes.

 gst-launch-1.0 --gst-debug=multifilesrc:5   multifilesrc location=%d.jpg ! jpegparse ! nvjpegdec ! mux.sink_0 nvstreammux width=1920 height=1080 batch-size=1 name=mux ! fakesink

result log info:

0:00:21.335788274  5215 0x55e7797ab8c0 DEBUG           multifilesrc gstmultifilesrc.c:392:gst_multi_file_src_get_filename: 4999
0:00:21.335811368  5215 0x55e7797ab8c0 DEBUG           multifilesrc gstmultifilesrc.c:425:gst_multi_file_src_create:<multifilesrc0> reading from file "4999.jpg".
0:00:21.335862082  5215 0x55e7797ab8c0 DEBUG           multifilesrc gstmultifilesrc.c:467:gst_multi_file_src_create:<multifilesrc0> read file "4999.jpg".
0:00:21.339953721  5215 0x55e7797ab8c0 DEBUG           multifilesrc gstmultifilesrc.c:392:gst_multi_file_src_get_filename: 5000
0:00:21.339976611  5215 0x55e7797ab8c0 DEBUG           multifilesrc gstmultifilesrc.c:425:gst_multi_file_src_create:<multifilesrc0> reading from file "5000.jpg".
Got EOS from element "pipeline0".
Execution ended after 0:00:20.775618410
Setting pipeline to NULL ...
Freeing pipeline ...

Could you give the link of yolov5 train or test dataset or your random generated pictures?
You can also check the compatibility with your env. It may be your environmental dependence problem.

Sorry.I’m trying coco dataset and didn’t reproduce this problem. But I think I found the problem. When I crashed, the picture I read can be decoded independently, the problem is the pics before this.

422.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 300x300, segment length 16, Exif Standard: [TIFF image data, big-endian, direntries=6, xresolution=86, yresolution=94, resolutionunit=2, copyright=(c) Creatista | Dreamstime.com], baseline, precision 8, 1300x1063, components 3.

and then read a normal jpg images with file info below:

423.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 500x374, components 3.

cmd will crash. Is there any problem to decode a format like 422.jpg?

Could you attach the 422.jpg to us? If you don’t want to share it to public, you can just message it to me. Or you can try to use the jpegdec plguin and check whether it’s still a problem.

it’s ok. I found lot’s of picture can reproduce this bug. These are two pics


It’s strange if you remove nvstreammux from pipeline, this won’t corrupt. In fact if using

 gst-launch-1.0 --gst-debug=multifilesrc:5   multifilesrc location=%d.jpg ! jpegparse ! nvjpegdec ! nvvideoconvert ! video/x-raw,format=RGBA ! fakesink

it won’t corrupt.
But using

 gst-launch-1.0 --gst-debug=multifilesrc:5   multifilesrc location=%d.jpg ! jpegparse ! nvjpegdec ! nvvideoconvert ! video/x-raw,format=RGBA,width=1920,height=1080 ! fakesink

error occurs

It’s a bug and we’ll fix it in the next vertion. At present, you can use the following workaround:

gst-launch-1.0 --gst-debug=multifilesrc:5   multifilesrc location=%d.jpg ! jpegparse ! jpegdec ! nvvideoconvert ! mux.sink_0 nvstreammux width=1920 height=1080 batch-size=1 name=mux ! fakesink

It’s nvjpeg’s bug or deepstream’s bug ? when will next version release?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.