Deepstream-image-decode-test for multiple images dynamically

Is it possible to use deepstream to run object detection on a folder full of images? It has to be dynamic i.e, model should not be loaded into the memory again for every image.

You can base on this sample “sources/apps/sample_apps/deepstream-image-decode-test” and modify. I will ask help about how to create_source_bin on a folder full of images.

You user can run detection on folder full of images using multifilesrc
You can refer to this link
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-multifilesrc.html

Thanks Chris. Will look into it and update.

Hello ChrisDing,
I tried to get the app deepstream-image-decode-test working on a sequence of jpg-images %d-camera0.jpg. I have the following problem.

The app seems to only process the first image in the sequence, but several times. That means if I have 100 images in the sequence, it processes the first image 0-camera0.jpg 100 times.

To reproduce that, run deepstream-image-decode-test on a sequence of jpg-images and check the output.

./deepstream-image-decode-app %d-camera0.jpg

Though, when I use the following gstreamer command, it works as expected.

gst-launch-1.0 multifilesrc location="%d-camera0.jpg" caps="image/jpeg,framerate=30/1" ! jpegdec ! x264enc ! avimux ! filesink location="out.avi"
1 Like

Have the same problem.

First, I’ve used multifilesrc together with jpegparse in my own app and got the same issue as [Deepstream-image-decode-test for multiple images dynamically). The gst-launch with multifilesrc works properly as well.

Next, I’ve moved to the reference application (deepstream-image-decode-test) and got the same issue: the application processes the first image n-times, where n is a total number of frames in directory.

Looking for a solution.

1 Like

Hi,

Also have the same problem, interesting enough, it seem to only happen on Jetson platform. On dGPU it works just fine.

I tried several decoders, none of them seem to have any effect, the first image gets processed then it seem to be forever locked into memory.

I managed to fix the problem by setting mjpeg option to true in the nvv4l2decoder gstreamer plugin.

It also seems nvidia updated deepstream sdk on 5.0 adding the very same fix when running on tegra.