Fwd: Error Releasing VideoCapture in OpenCV Using GStreamer Pipeline
Gaspar Ramôa
ramoa.science at gmail.com
Fri Nov 15 11:01:48 CET 2024
Dear all,
Thank you everyone for clarifying everything and answering every question.
Regarding the different frame size that gstreamer, I can for now work
with 1600x1200 instead of the 1640x1232, that is not a burden for me.
Best Regards,
Gaspar
On 15/11/2024 09:28, Naushir Patuck wrote:
> On Fri, 15 Nov 2024 at 00:25, Laurent Pinchart
> <laurent.pinchart at ideasonboard.com> wrote:
>> 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 think this is probably related to
> https://bugs.libcamera.org/show_bug.cgi?id=169
> since (I assume) gstreamer expected a 32-byte aligned stride. A width
> of 1640 is not a multiple of 32, but 1600 is.
>
> Naush
>>> 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