Problem running deepstream-test3 with IP camera

Hi

I’m using Jetson Nano, with Jetpack3.2.1 and deepstream SDK4.0.

I can successfully run this cmdline and get real-time images shows up:

gst-launch-1.0 rtspsrc location=\"rtsp://admin:password@192.168.1.11:554/h264/ch1/main/av_stream\" latency=0 ! rtph264depay ! h264parse ! omxh264dec ! nvvidconv ! xvimagesink sync=flase

I haven’t modified deepstream_test3_app.c.
And when I run:

make
./deepstream-test3-app rtsp://admin:password@192.168.1.11:554/h264/ch1/main/av_stream

I got this and no image shows up:

Now playing: rtsp://admin:password@192.168.1.11:554/h264/ch1/main/av_stream,

Using winsys: x11
Creating LL OSD context new
0:00:00.932255312 14509 0x555efaed90 INFO nvinfer gstnvinfer.cpp:519:gst_nvinfer_logger: NvDsInferContext[UID 1]:initialize(): Trying to create engine from model files
0:00:00.932456614 14509 0x555efaed90 WARN nvinfer gstnvinfer.cpp:515:gst_nvinfer_logger: NvDsInferContext[UID 1]:generateTRTModel(): INT8 not supported by platform. Trying FP16 mode.


I want to know how to fix this?
Is there anything I havn’t done before I run deepstream-test3?

Any advice will be a huge help for me, THANKS!

Hi,
It looks to be normal prints that nvinfer is creating engine file. The default config file is for Xavier. Please check the following post to modify it for Nano:
https://devtalk.nvidia.com/default/topic/1058597/deepstream-sdk/-nano-deepstream-test3-app-not-working-as-expected-for-multiple-video-source/post/5368352/#5368352

Hi,
Thanks for Replying.

I did what you suggest, and now errors have gone.

I can use

./deepstream-test3-app file:<mp4 file absolute path>

to play .mp4 source perfectly.

But when I run

./deepstream-test3-app rtsp://admin:password@192.168.1.11:554/h264/ch1/main/av_stream

The window “deepstream-test3-app” shows up, but no image in it, it’s stuck with my desktop image in it.

And I got print:

WARNING: Overriding infer-config batch-size (8) with number of sources (1)
Now playing: rtsp://admin:password@192.168.1.11:554/h264/ch1/sub/av_stream,

Using winsys: x11
Creating LL OSD context new
0:00:01.356441145 12759 0x55ac1dcb90 WARN nvinfer gstnvinfer.cpp:515:gst_nvinfer_logger: NvDsInferContext[UID 1]:log(): Using an engine plan file across different models of devices is not recommended and is likely to affect performance or even cause errors.
Decodebin child added: source
Running…
Decodebin child added: decodebin0
Decodebin child added: rtph264depay0
Decodebin child added: h264parse0
Decodebin child added: capsfilter0
Decodebin child added: decodebin1
Decodebin child added: nvv4l2decoder0
Seting bufapi_version
Decodebin child added: rtppcmadepay0
Decodebin child added: alawdec0
In cb_newpad
Opening in BLOCKING MODE
NvMMLiteOpen : Block : BlockType = 261
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 261
In cb_newpad
Creating LL OSD context new

Compare to the right print when I run with .mp4 source, the print stop at “Creating LL OSD context new”, and no further print like"Frame Number = 0 Number of objercts = 0 Vehicle Count = 0 Person Count = 0"print out

How to debug this problem? Since I can run the rtsp with gst-launch-1.0, I think my IP Camera device runs well.I don’t know what to do with this now.

Hi,
Please replace the prebuilt libs in this post, clean gstreamer cache and try again.

Hi,
when I run

unzip R32_2_DS_4_0_PREBUILT_LIB.zip

I got this

End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of R32_2_DS_4_0_PREBUILT_LIB.zip or
        R32_2_DS_4_0_PREBUILT_LIB.zip.zip, and cannot find R32_2_DS_4_0_PREBUILT_LIB.zip.ZIP, period.

It seems the zip is broken?
Can you reupload it please? Thanks

You may try https://www.7-zip.org/

Hi DaneLLL,
Thanks, I replace the prebuild lib and clean gstreamer cache, problem solved!!

The zip problem blames to Chrome.

Thanks a lot for your excellent work nvidia team!