I am encountering a persistent issue with RTSP streams in Python applications on the DeepStream 6.4 SDK, using the Docker image nvcr.io/nvidia/deepstream:6.4-triton-multiarch. These applications consistently fail with RTSP streams, leading to an “Aborted (core dumped)” error. Notably, these issues are exclusive to RTSP inputs as the applications function correctly when using video files as input. This error does not occur in the C versions of these applications (e.g., apps/deepstream-test3), which run without issues in the same environment.
Configuration Details
Environment: Running on a dGPU, not Jetson.
Key Observations
The problem occurs across various Python RTSP applications like apps/deepstream-imagedata-multistream and apps/deepstream-test3.
Simple OpenCV applications within the same Docker container can access and display the RTSP stream, indicating no network issues.
Using --network host and checking for port conflicts (nothing bound to 554) have not resolved the issue.
Request for Help
I am seeking insights or solutions to this Python-specific RTSP handling issue in DeepStream 6.4. The error “Aborted (core dumped)” appears consistently when using RTSP as the input, whereas video file inputs do not provoke this error. Has anyone else faced similar challenges or could offer troubleshooting advice? Any suggestions or guidance would be greatly appreciated!
Thank you for your response. I have confirmed that the Python bindings for DeepStream (pyds) are installed correctly on my Docker container. I installed pyds using the pyds-1.1.10-py3-none-linux_x86_64.whl file. The version of pyds installed is 1.1.10, as verified in the Python environment :
Any insights or further troubleshooting steps you could suggest would be greatly appreciated.
Regarding the dependencies of pyds, I have confirmed their installation, and deepstream-test1.py runs successfully using a .h264 video file as input. This suggests that the basic setup and dependencies for the DeepStream Python environment are correctly configured.
However, as mentioned in my initial message, the issue with deepstream-test3.py arises specifically when using an RTSP stream as input. This application works correctly when using a video file as input on the same Docker image. The problem only occurs with RTSP input.
I followed your instruction to use gdb to dump the crash stack. The command I used for the RTSP input was:
The C version of the test 3 application runs successfully with the RTSP stream specified (rtsp://admin:admin123@192.168.10.68:554/cam/realmonitor?channel=1&subtype=1) on the same Docker container. This indicates that the RTSP stream itself is accessible and functions correctly in this environment.
Furthermore, the Python version of the application, deepstream-test3.py, operates correctly with video files as input but encounters issues exclusively when fed with RTSP streams in the same Docker container. This suggests that the issue may be specific to how the Python application handles RTSP inputs.
Thank you for your assistance in resolving the issue.
After following your instructions and reinstalling PyDS using the provided command line, I’m happy to report that the problem has been successfully resolved. It appears that the PyDS installation through the user_additional_install.sh and user_deepstream_python_apps_install.sh scripts included additional dependencies that were necessary for proper functionality.
To reinstall PyDS, I executed the following commands within the DeepStream container:
cd /opt/nvidia/deepstream/deepstream
./user_additional_install.sh
./user_deepstream_python_apps_install.sh -v 1.1.10
This installation method proved to be effective, and I no longer encounter any issues with reading RTSP streams in Python applications on the Docker container.
I believe the initial problem stemmed from my attempt to install PyDS using its wheel (whl) file and manually copying and installing PyDS. It appears that this method did not include all the necessary dependencies, which led to errors when trying to use PyDS especially for RTSP stream handling.
Your suggestion to use the provided installation scripts was instrumental in resolving the issue, as it ensured that all required dependencies were properly installed.
Once again, thank you for your prompt and helpful support throughout this process.