Fwd: Error Releasing VideoCapture in OpenCV Using GStreamer Pipeline
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Fri Nov 15 01:24:48 CET 2024
Hi Gaspar,
On Thu, Nov 14, 2024 at 12:28:14PM +0100, Gaspar Ramôa wrote:
> Hello Laurent,
>
> Sorry for the double reply, but I was already able to solve the problem
> I sent you in the previous email.
That's good news, I won't complain that I didn't have to help you :-)
> Here's the solution, (I might create another issue on GitHub and close
> it with the solution to help others):
>
> I am still quite not sure, but basically gstreamer does not support the
> same *frame sizes* has the ones from the *sensor format*.
>
> When I do the command: *rpicam-vid --list-cameras: *I get the following
> sensor format: 1640x1232 - 41 FPS
> Available cameras
> -----------------
> 0 : imx219 [3280x2464 10-bit RGGB] (/base/soc/i2c0mux/i2c at 1/imx219 at 10)
> Modes: 'SRGGB10_CSI2P' : 640x480 [103.33 fps - (1000, 752)/1280x960 crop]
> *1640x1232* [41.85 fps - (0, 0)/3280x2464 crop]
> 1920x1080 [47.57 fps - (680, 692)/1920x1080 crop]
> 3280x2464 [21.19 fps - (0, 0)/3280x2464 crop]
> 'SRGGB8' : 640x480 [103.33 fps - (1000, 752)/1280x960 crop]
> *1640x1232* [41.85 fps - (0, 0)/3280x2464 crop]
> 1920x1080 [47.57 fps - (680, 692)/1920x1080 crop]
> 3280x2464 [21.19 fps - (0, 0)/3280x2464 crop]
>
> In the gstreamer pipeline I was using this format size, and although I
> was getting 41 fps, my frames had this *striping *effect.
>
> * libcamerasrc camera-name=/base/soc/i2c0mux/i2c at 1/imx219 at 10 !
> video/x-raw,*width=1640,height=1232*,format=RGBx,framerate=41/1 !
> videoconvert ! appsink
As Nicolas replied separately, there's a patch that was submitted very
recently to fix this. It's under review, I hope to merge it soon once
all reviews comments are addressed.
> After looking up, I installed gstreamer1.0-plugins-base-apps and use the
> command *gst-device-monitor-1.0 Video *to check which gstreamer video
> streaming formats were available for my camera. And I checked that there
> was no 1640x1232 option, but a similar one 1600x1200 (same ratio as
> 640x480). I then tried with this frame size format and it is now working
> at 41fps with no striping effect:
>
> * libcamerasrc camera-name=/base/soc/i2c0mux/i2c at 1/imx219 at 10 !
> video/x-raw,*width=1600,height=1200*,format=RGBx,framerate=41/1 !
> videoconvert ! appsink
I'm not sure what logic rpicam-vid uses to determine the formats it
lists as supported. We may be using a different logic in libcamerasrc.
That's something we should look at. If it bothers you, could you please
file a bug on bugs.libcamera.org to track the issue ? I can't promise to
look at it very quickly though, but it will then be on our list.
> I just have another short question. Now that gstreamer works properly
> and I can release the capture without that warning/error. I want to know
> if I can use libcamerasrc without having to activate this environment
> under /libcamera/build/ with *meson devenv -C build. *If I don't do
> this, I cannot use gstreamer with libcamerasrc, the libcamerasrc is not
> recognize for some reason.
>
> Isn't it possible to just install libcamera where *libcamerasrc *is
> available without this virtual environment?
GStreamer looks for plugins in the $GST_PLUGIN_PATH and
$GST_PLUGIN_SYSTEM_PATH directories. The directory containing
libgstlibcamera.so in your build directory is not known to GStreamer, so
it won't find the element. You can either install libcamera to the
system, which will copy the libgstlibcamera.so file to the GStreamer
system pluings directory, or set GST_PLUGIN_PATH to point to the
src/gstreamer/ directory in your build tree. This is what "meson devenv"
does, see src/gstreamer/meson.build:
--------
# Make the plugin visible to GStreamer inside meson devenv.
fs = import('fs')
gst_plugin_path = fs.parent(libcamera_gst.full_path())
gst_env = environment()
gst_env.prepend('GST_PLUGIN_PATH', gst_plugin_path)
# Avoid polluting the system registry.
gst_env.set('GST_REGISTRY', gst_plugin_path / 'registry.data')
meson.add_devenv(gst_env)
--------
> On 13/11/2024 19:00, Gaspar Ramôa wrote:
> >
> > Hello Laurent Pinchart,
> >
> >
> > Thank you for the quick reply!
> >
> > As I created the issue 3 months ago and got no reply from you I
> > thought that you were no longer active or working in this project, and
> > that is why I said it was difficult to get you! But I am glad I was
> > able to reach you! :-)
> >
> > I spent the entire afternoon following your suggestion.
> >
> > So I was successfully able to install the latest version of libcamera
> > and the latest version of the rpicam-apps:
> >
> > /rpicam-apps build: v1.5.3 50958df98d3c 13-11-2024 (16:55:55)
> > rpicam-apps capabilites: egl:1 qt:1 drm:1 libav:1
> > libcamera build: v0.3.2+98-75fe515a/
> >
> > However when trying to run *gst-inspect-1.0 libcamerasrc *the system
> > could not find the libcamerasrc. I had to activate some environment
> > under /libcamera/build/ with *meson devenv -C build*
> >
> > After this I was able to start the capture and release it *without any
> > errors or warnings*. This is really a great positive step for me!
> >
> > The frame saved is still weird but I think you probably know what is
> > missing here. I know that I still have to use some tunnig-files but
> > the horizontal strips I have no idea what they are. I am using *format
> > *= BGR and x-raw video on the gstreamer pipeline. Do you have any idea
> > on how to convert these to the normal RGB. Like using the
> > *rpicam-still *-o test.png gives me this:
> >
> > And I able getting something like this from the gstreamer pipeline:
> >
> > Any ideas? Where can I find the documentation of *libcamerasrc *so I
> > can have an idea on what I can change/do.
> >
> >
> > My end goal is to just be able to use the benefits of libcamera
> > (changing analog gain, exposure, etc) in JAVA.
> >
> >
> > Best Regards,
> >
> > Gaspar Ramôa
> >
> >
> > On 13/11/2024 14:35, Laurent Pinchart wrote:
> >> Hello Gaspar,
> >>
> >> On Wed, Nov 13, 2024 at 12:51:11PM +0100, Gaspar Ramôa wrote:
> >>> Dear libcamera community,
> >>>
> >>> Thank you for developing such a helpful library.
> >> I'm glad you find it helpful.
> >>
> >>> I am trying to get frames using opencv. I am actually able to get frames via
> >>> cv2.VideoCapture through GStreamer.
> >>>
> >>> However, when I try to release the capture (for ending the program or maybe
> >>> adjusting raw image size): cap.release()
> >>> I get the following error:
> >>>
> >>> [1:39:52.854669803] [1885] ERROR DeviceEnumerator device_enumerator.cpp:172
> >>> Removing media device /dev/media4 while still in use
> >>> [1:39:52.854709759] [1885] ERROR DeviceEnumerator device_enumerator.cpp:172
> >>> Removing media device /dev/media3 while still in use
> >>>
> >>> I've already published an issue on the raspberry Pi libcamera GitHub repo where
> >>> you can get more detail on my problem:https://github.com/raspberrypi/libcamera
> >>> /issues/163
> >>>
> >>> I found the following commit which apparently did to solve the problem I am
> >>> having now:https://github.com/raspberrypi/libcamera/commit/
> >>> fa63d428aef62bacf0a6ad1622a7965b3ff2ba2f
> >> That commit has been merged a long time ago, before v0.0.1, so I expect
> >> it is included in the libcamera version you are using. Your problem may
> >> have the same symptoms but a different root cause.
> >>
> >> You mentioned in your bug report that you tried both libcamera v0.0.5
> >> and v0.3.0+65-6ddd79b5. v0.0.5 is fairly old. v0.3.0 is better, but I
> >> would still recommend trying the latest master branch to see if the
> >> issue has been fixed already.
> >>
> >> If the issue is still present, can you try running the same GStreamer
> >> pipeline (likely replacing appsink with some sort of display sink, or
> >> even fakesink) from gst-launch, and see if the problem exists there too
> >> ?
> >>
> >>> This commit was done by the userhttps://github.com/pinchartl. But I have no
> >>> way of contacting him to help me fix the problem.
> >> I'm slightly puzzled by why you had trouble contacting me, given that my
> >> e-mail address is listed in the commit you mentioned above. Regardless,
> >> it looks like you found a way :-)
> >>
> >>> Any suggestions? Thanks in advance!
--
Regards,
Laurent Pinchart
More information about the libcamera-devel
mailing list