Hi @pulzappcheck890, when you created the file, did you create it inside or outside the container? The container only sees files that are inside it, unless you mount them in.
For example, starting the jetson-inference container with docker/run.sh --volume /home/usr:/mount will mount usr’s home directory to the location /mount inside the container. Hope that helps!
Hi @dusty_nv , i tried to mount the folder as you instructed on the above message. Now the shmsink socket file is being generated in the mounted folder. Now, the socket file cannot be read inside a docker container or in the regular terminal to view the video feed
Hi @pulzappcheck890, I’m not sure what you are referring to with the shmsink socket file? Perhaps change it’s path to one not in the mounted volume? Or make sure the permissions of the mounted volume are correct, and that it exists on an ext3/ext4 partition
We are using gstreamer’s shmsink to sink an input audio/video stream to a shared memory location(a file is created in the given location) that can be accessed using shmsrc to preview and use for other purposes.
We have tested this scenario by creating a python code to receive an rtsp stream and process it and sink the audio/video using shmsink and preview it using shmsrc which is working without any errors.
Now we are using jetson inference which is running inside a docker, to add some more processing like object detection to the same rtsp feed where everything is working fine. We also were able to create a shmsink file (shared memory file) inside a mounted folder in the docker after the video processing is done. The issue we have is accessing that file using shmsrc. It says permission is denied.
We also tried creating a text file from the same python code in the same location and it was accessible.
Is this a file permission issue when running inside the docker?
How can we resolve this error?
Or Can we use the jetson inference building and installation without docker and try if the same issue exists?
Typically when you create a file in container, it is created with root write-only privileges (unless you specifically created another used in your container). I don’t believe this prevents other uses from reading the files though. You can manually set the file access rights with chmod/ect though (I’m not sure about special shared memory files). You could also try creating your file in a different container (like l4t-base) just a test to see if the behavior is the same or not.