Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot access camera via gstreamer nvarguscamerasrc in docker container. #1518

Open
mo-krauti opened this issue Apr 3, 2024 · 7 comments
Open

Comments

@mo-krauti
Copy link

I am trying to access an imx477 camera connected via csi to a jetson xavier nx using the devkit board. I built the meta-tegra-demo on branch kirkstone using the base image and the following packages:

IMAGE_INSTALL:append = " \
    nvidia-docker \
    cuda-libraries \
    balena-engine \
    balena-engine-config \
    python3-jetson-stats \
    tegra-libraries-camera \
    gstreamer1.0 \
    gstreamer1.0-plugins-base \
    gstreamer1.0-plugins-tegra \
    gstreamer1.0-plugins-good \
    gstreamer1.0-plugins-bad \
    tegra-libraries-multimedia-v4l \
    tegra-container-passthrough \
    vim \
"

I am able to record a test video on the host system using:

gst-launch-1.0 -e nvarguscamerasrc sensor-id=0 ! "video/x-raw(memory:NVMM),width=1920,height=1080,framerate=40/1" ! nvv4l2h264enc ! h264parse ! mp4mux ! filesink location=video.mp4

Then I launched the container using:

docker run -it --ipc=host -v /tmp/argus_socket:/tmp/argus_socket --cap-add SYS_PTRACE --device /dev/video0:/dev/video0 --gpus all --rm  nvcr.io/nvidia/l4t-base:35.4.1 bash

I tried the test video command and this simplified test: gst-launch-1.0 -e nvarguscamerasrc sensor-id=0 ! fakesink.
Both result in the following error:

Setting pipeline to PAUSED ...
Opening in BLOCKING MODE
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
NvMMLiteOpen : Block : BlockType = 4
===== NvVideo: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
GST_ARGUS: Creating output stream
(Argus) Error InvalidState: Failed to load EGL library (in src/eglutils/EGLUtils.cpp, function exports(), line 213)
(Argus) Error InvalidState: Failed to get EGL API access function (in src/eglutils/EGLUtils.cpp, function exports(), line 224)
Caught SIGSEGV
exec gdb failed: No such file or directory
Spinning.  Please run 'gdb gst-launch-1.0 9' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.

^Chandling interrupt.
Interrupt: Stopping pipeline ...
EOS on shutdown enabled -- Forcing EOS on the pipeline
^C

I looked at the nvargus-daemon logs in the host system, but could not find any errors besides those also shown when running the command in the host system successfully.

Am I missing something?

@mo-krauti
Copy link
Author

Also I am running into an error when adding the --privileged flag to the docker run command:

docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: nvidia-container-cli: mount error: file creation failed: /var/data/balena-engine-data/overlay2/9be0cd6e640bc611cd4eaeddae49c7fd5a4ea94770a013e249421cff28b95259/merged/dev/nvgpu/igpu0/as: invalid argument: unknown.

This seemed similiar to this thread, but should be fixed in our version of nvidia-container-toolkit. Is it possible that this is related to mode = "legacy" in /etc/nvidia-container-runtime/config.toml?

@madisongh
Copy link
Member

Have you tried this with the latest changes on kirkstone? There were some fixes for the container toolkit support that went in at the end of April that eliminated the need to use 'legacy' mode.

@mo-krauti
Copy link
Author

I retried it using commit d6c3b9c15eda222a401e65e7b85c9419341a0a3e (from june) of the tegra-demo-distro and it still did not work. I will try it using the latest commit soon.

@mo-krauti
Copy link
Author

Now I tried it again using the latest commit 34bb59c85d356478e6868550822818ca268018a1 which did not work either.

@juliermeSilva
Copy link

juliermeSilva commented Nov 13, 2024

I'm having the same problem when trying to access the Raspberry PI v2.1 camera inside a docker container.
On the Jetson Nano host the camera works perfectly. But inside the container it doesn't.
OpenCV with access to GSTREAMER successfully installed in the container. GSTREAMER dependencies successfully installed in the container.

My container:

docker run -it -d --gpus all --name test4 --privileged --network host --ipc=host \
  -e DISPLAY=:0.0 \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -v /dev:/dev \
  -v /home:/home \
  -v /tmp/argus_socket:/tmp/argus_socket \
  -v /usr/lib/aarch64-linux-gnu/tegra:/usr/lib/aarch64-linux-gnu/tegra \
  -v /usr/lib/aarch64-linux-gnu/tegra-egl:/usr/lib/aarch64-linux-gnu/tegra-egl \
  -p 2225:22 \
  ultralytics/ultralytics:latest-jetson-jetpack4

Error seen in the terminal:

root@jetson:/ultralytics# gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM), width=640, height=480, framerate=30/1' ! nvvidconv ! 'video/x-raw, format=(string)BGRx' ! videoconvert ! xvimagesink
(Argus) Error FileOperationFailed: Connecting to nvargus-daemon failed: Connection refused (in src/rpc/socket/client/SocketClientDispatch.cpp, function openSocketConnection(), line 205)
(Argus) Error FileOperationFailed: Cannot create camera provider (in src/rpc/socket/client/SocketClientDispatch.cpp, function createCameraProvider(), line 106)
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:735 Failed to create CameraProvider
Got EOS from element "pipeline0".
Execution ended after 0:00:00.003569630
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

@dwalkes
Copy link
Member

dwalkes commented Nov 13, 2024

Do you see anything in nvargus-daemon logs?

Based on https://forums.developer.nvidia.com/t/resolving-video-capture-error-in-docker-container-after-restarting-nvargus-daemon/271196/3 you may want to try volume mounting /tmp instead of /tmp/argus_socket.

If that doesn't work I'd probably install the equivalent Jetpack image and prove docker works there with the same hardware, use this to compare with your setup.

@juliermeSilva
Copy link

I solved the issue of accessing the Raspberry PI v2.1 Camera, inside a container.
The container creation was correct. I had already installed all the dependencies related to GStreamer.
The error was occurring on my system for two reasons:

  • Reason 1 - Granting permission to the X server for connections from a specific user. I was not granting permissions. Before starting the docker container I ran the command:
    xhost +si:localuser:root

  • Reason 2 - As I mentioned I had already granted all access privileges when creating the container. I created the correct container but tested it incorrectly. The error visible in the previous post is consistent with an incompatible graphics sink in the GStreamer pipeline. The error occurs specifically because xvimagesink is not available or functional in the container environment. Before attempting any communication with GStreamer inside the container, check if the communication plugin is present inside the container using the command:
    gst-inspect-1.0 | grep sink
    When I ran this command inside my container, two sinks appeared in the list: appsink and nveglglessink.
    I used the nveglglessink sink (developed by Nvidia) to do a new test, rendering the stream directly to a screen using EGL/GLES (taking advantage of NVIDIA hardware graphics acceleration).
    The new test:

gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM), width=640, height=480, framerate=30/1' ! nvvidconv ! 'video/x-raw, format=(string)BGRx' ! videoconvert ! nveglglessink

This time a window showing the camera appeared, proving the connectivity of the container with the Raspberry PI V2.1 camera, via GStreamer.
WhatsApp Image 2024-11-13 at 02 41 11

Next, I wrote a simple Python code to test the GStreamer reading within an application. This time, the sink used was appsink, since it is designed to allow the GStreamer pipeline to send video or audio data directly to an application, such as a Python script, where it will be possible to process the frames, perform AI inference, save to files or perform other custom operations.
The python code:

import cv2

# Define the GStreamer pipeline to access the Raspberry Pi v2.1 camera
gst_pipeline = (
    "nvarguscamerasrc ! "
    "video/x-raw(memory:NVMM), width=(int)640, height=(int)480, framerate=(fraction)30/1 ! "
    "nvvidconv ! video/x-raw, format=(string)BGRx ! "
    "videoconvert ! video/x-raw, format=(string)BGR ! appsink"
)

# Initialize video capture with the GStreamer pipeline
cap = cv2.VideoCapture(gst_pipeline, cv2.CAP_GSTREAMER)

if not cap.isOpened():
    print("Error: Unable to access the camera!")
    exit()

print("Camera accessed successfully!!")

while True:
    ret, frame = cap.read()
    if not ret:
        print("Error: Unable to capture the frame!")
        break

    # Display the captured frame
    cv2.imshow("Raspberry Pi cam", frame)

    # Press 'q' to exit (quit)
    if cv2.waitKey(1) & 0xFF == ord('q'):
        break

# Release the camera and close the windows
cap.release()
cv2.destroyAllWindows()

I hope I have contributed something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants